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PREFACE 



The growth and widespread adoption of Internet technologies have enabled a 
wave of innovations that are having an important impact on the way 
businesses deal with their partners and customers. To remain competitive, 
traditional businesses are under pressure to take advantage of the 
information revolution brought about by the Internet and the Web. Many 
businesses are moving their operations to the Web for greater automation, 
more efficient business processes, customization, and global visibility. 

Web services technology is an important infrastructure toolkit that is helping 
businesses become more Web-oriented, and in particular to expose 
application interfaces via the Web. Major standards initiatives, such as 
SOAP, WSDL, and UDDI, have been launched with industry-wide support, 
with the aim of allowing client applications to automatically discover and 
interoperate with Web services. A cottage IT industry has arisen for 
developing infrastructure for robust Web services, and for addressing critical 
issues such as security, reliability, and adaptability. Solutions are being 
developed to allow businesses to connect to their business partners via Web 
services for more effective Business-to-Business (B2B) transactions, or 
within enterprises for more efficient operations. 

Despite all the effort invested in Web services infrastructure and 
development, the promise of loosely coupled large applications, assembled 
from heterogeneous distributed services, is still a long way off. Current 
industry standards do not allow a Web service’s capabilities and operating 
constraints to be described in a manner that enables automatic discovery and 
deployment of services that satisfy complex needs. Further, some business 
solutions may require composition of multiple services (e.g., flight-, hotel-, 
and rental-car reservation) into a single complex service (e.g., a travel- 
reservation service). General automated composition requires techniques 
beyond those provided by current standard Web service technologies. 
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Many of the challenges faced by the Web services community in its aim of 
building tools and techniques for loosely-coupled systems have been 
investigated within the Multi-Agent System (MAS) community. In 
particular, research into MAS has addressed the problem of describing 
capabilities for components (i.e., software agents) in an open environment; 
automatically discovering and composing such components into systems that 
satisfy specified needs; and managing execution to ensure robust and reliable 
system performance. Some issues that are of specific critical interest to 
business communities, such as security and transaction integrity, have 
received less attention in MAS research; however, these are challenges that 
are far from resolved in the Web services community and may also benefit 
from MAS approaches. 

While a Web service need not fulfill all features of a strong definition of a 
software agent, the Web services approach to building complex software 
systems bears similarities to agent-oriented system engineering approaches. 
In particular, large systems are assembled from distributed heterogeneous 
software components, each providing a specialized service or capability. 
Similarly to multi-agent engineering paradigms, the design process of such 
systems focuses on the declarative characterization of the software agents' 
capabilities and on a message -based paradigm of interoperation. 

The parallels between Web services infrastructure and Multi-Agent Systems, 
and the potential for MAS techniques to impact Web services systems 
engineering, has not escaped the MAS R&D community. Recent years have 
seen much activity in using and extending MAS infrastructure and 
technology to address issues and concerns to the Web services community. 

This Volume 

The stimulus for this particular volume was a workshop on Web Services 
and Agent-Based Engineering (WSABE), held in conjunction with the 
Second International Joint Conference on Autonomous Agents and Multi- 
Agent Systems (AAMAS), held in Melbourne, Australia, in July 2003. A 
selection of the authors from that workshop were invited to extend and 
revise their papers, and a selection of prominent researchers from the 
intersection of the fields of Web services and Multi-Agent Systems were 
invited to also submit papers. All papers went through multiple review 
cycles. The final collection of papers covers a range of topics at the cross- 
section of Web services, Multi-Agent Systems, and the related area of Grid 
Computing. 
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IX 



The first two chapters deal with infrastructure and architecture issues. 
Chapter 1 , by Casati et al, presents a framework for enabling the automated 
management of an enterprise's IT infrastructure. It argues that the formula 
for adaptive business-driven management is based on the basic architectural 
principle of Web service orientation, and on certain key technological 
ingredients such as resource virtualization. Chapter 2, by Papazoglou et al, 
introduces an extended service-oriented architecture that provides separate 
tiers for composing and coordinating Web services, and for managing Web 
services in an open marketplace. In addition, this chapter discusses how 
software agents can be used to support the functions of the extended service- 
oriented architecture. 

Semantic Web services, and the associated development of OWL-S, is a 
major sub-theme of this volume, reflecting a specifically important way in 
which Multi-Agent Systems research promises to impact Web services. 
Chapter 3, by Martin et al, argues that the work on Semantic Web services 
provides the richer specifications of Web services needed to enable fuller, 
more flexible automation of service provision and use, to support the 
construction of more powerful tools and methodologies, and to promote the 
use of semantically well-founded reasoning about services. This chapter 
provides an overview of OWL-S (a Semantic Web services ontology and 
associated techniques) and discusses its connections with work on agent- 
based systems. Chapter 4, by Paolucci et al, firstly provides an analysis of 
the Brokering task for Semantic Web services. It then demonstrates that a 
Broker implementation based on the OWL-S standard is problematic, 
arguing for an extension to the OWL-S process modeling language. 

Chapter 5, by Lyell, discusses how an agent-centric system, based on the 
FIPA agent standards, can interact with systems developed using other 
frameworks. In particular, it presents an architecture that uses Web services 
to facilitate interactions among agent-based systems and Web-accessible 
legacy applications. Chapter 6, by Johnson et al, presents a fine-grained 
semantic policy service for the management of Open Grid Service 
Architecture (OGSA)-compliant services. This is implemented using KaoS, 
an agent-based collection of services for distributed architectures. 

Chapter 7, by Maamar et al, presents an agent-based methodology for 
developing service-oriented applications. The authors discuss how users can 
compose services and how dynamic selection of services is performed based 
on criteria such as execution cost and location of resources. Chapter 8, by 
Rana et al, addresses the issue of quality of service, i.e., non-functional 
characteristics of services such as performance, reliability, and cost. It 
presents a mechanism that can lead to more effective service discovery and 
selection, including selection based on quality of service. 
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An important potential application of agent-based techniques is in creating 
more complex services from simpler components, by automated composition 
and via interactive conversations. Chapter 9, by Ardissono et al, 
investigates the extension of Web service protocols to support possibly long- 
lasting conversations, using a formalism based on Speech Act Theory to 
specify conversation primitives. Chapter 10, by Laukkanen and Helin, and 
Chapter 11, by Richards et al, each describe approaches to composing 
Semantic services. Laukkanen and Helin use an approach based on 
integrating services into a workflow, using properties of services 
(preconditions, effects, etc) classified against an ontology. Richards et al 
apply their Agent Factory, a knowledge-based approach to designing agents, 
to specify composition of Semantic Web services. 

In Chapter 12, Barbera-Medina et al apply techniques from multi-agent 
systems research to the brokering problem, specifically for mathematical 
services; however, the techniques have potential application to wider classes 
of semantic services. Chapter 13, by Jin and Goschnick, addresses the 
problem of transactions, a critical (and unresolved) issue for widespread 
adoption of Web service-based applications. Jin and Goschnick start by 
surveying the different approaches to transaction management, before laying 
out a new approach using agent-based techniques. On service failure, the 
transaction manager may draw from a pool of alternative services that have 
similar functionality to the failed service in order to complete the 
transaction. In Chapter 14, Gutierrez and Huhns propose a related approach 
to service reliability: multiple possible implementations of services 
providing similar functionalities, but applicable in different circumstances, 
provide a greater tolerance to error. 

This volume covers a range of important issues in the cross-section of Web 
services and software agents, in particular, focusing on the potential for 
techniques from Multi-Agent Systems R&D to impact the difficult 
challenges that must be addressed for Web services technology to realize its 
promises. However, these contributions represent the tip of an ever- 
expanding iceberg: the area of Web services is one of the fastest developing 
in the general area of enterprise systems engineering, and the promise of 
Multi-Agent Systems techniques has been quickly recognized. Such research 
is now commonly found in the mainstream of the Web services research 
literature, and more recent developments in this fast-growing area can be 
found in a variety of conferences, such as the International Semantic Web 
Conference (ISWC) and the International Conference on Web Services 
(ICWS). 
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Chapter 1 

TECHNOLOGIES FOR BUSINESS-DRIVEN 
INFORMATION TECHNOLOGY MANAGEMENT 



Vijay Machiraju, Claudio Bartolini, Fabio Casati 
Hewlett-Packard , Palo Alto , CA, USA 
firstname.lastname@hp.com 



1. INTRODUCTION 

In recent years, the industry is witnessing several significant trends that 
are changing the way companies think about their IT infrastructure and 
about how it should serve their business. The first is the increased cost of 
managing the IT infrastructure. In fact, while the cost for purchasing 
hardware is constantly going down, the labor cost for managing hardware 
and software of ever increasing complexity is not. Indeed, the cost or 
management has recently overtaken the cost for the hardware, and is 
predicted to become three times as expensive as the HW cost over the next 
few years. This makes it clear that companies are now hungry for techniques 
that help them to dramatically reduce the IT management cost, especially at 
a time where cost control is considered to be of paramount importance. 

Another trend that is significant to the topics discussed in this chapter is 
the quest for a greater alignment of the IT infrastructure with the business 
needs. In the past, the opportunity for such an alignment was not there, as 
the IT was only supporting a small part of the business operations, the 
remainder being carried out manually to a large extent. Nowadays, however, 
the level of automation in the companies' business processes is rapidly 
increasing. As more and more business operations are supported by IT, the 
quality and efficiency with which IT operations are performed has a growing 
impact on how the business is performed, and the achievement of business 
objectives depends more and more on how the IT environment can support 
the business. 
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Finally, another trend that is sweeping across the industry is the desire for 
an adaptive (or autonomic) IT infrastructure. Indeed, many people perceive 
the current business climate as being much more dynamic than it used to be 
only a decade ago, both in terms of business partnerships and in terms of 
customers' behavior. Coping with continuous change in the business climate 
implies the need for an IT infrastructure that dynamically adapts to such 
changes, and is able to deliver with adequate performance and quality levels 
under different and changing conditions. 

Recognizing these needs and the enormous business opportunities that 
come with them, many large scale IT vendors have put in place programs 
that are targeted at enabling such a dynamic, business-driven IT 
infrastructure. The most significant efforts to date are IBM's autonomic 
computing 18 program and HP's adaptive enterprise 15 program. 

In this chapter we provide a vision for an adaptive IT infrastructure 
driven by business goals. We show the requirements for such an 
infrastructure, and then discuss the technologies and the architecture that 
enable this vision. We structure the problem into layers at different levels of 
abstractions, from the business process level down to the hardware level, and 
we show how management technologies can statically and dynamically 
improve business operations within each layer and across layers, with the 
ultimate goal of having all the layers of a company's IT infrastructure 
synchronized and work together to meet high-level business goals, adapting 
to ever-changing conditions. 

As this chapter shows, we believe that Web services and Service- 
Oriented Architectures (SOAs) will be a key part of both the IT 
infrastructure and its management system. There are two ways in which Web 
services contribute to making business-driven management possible: First, 
they abstract the heterogeneity in IT infrastructure through a set of well- 
defined interfaces. In fact, as shown later in this document, the main benefit 
of Web services is that of standardizing the way functionality of various IT 
elements is exposed (e.g., through the use of common protocols and data 
models), thereby removing much of the heterogeneity present in current IT 
infrastructures. This makes it easier to develop generic management 
components that can interoperate with a number of IT elements. 

The second way in which Web services enable business-oriented 
management is by making the management system itself more homogeneous 
and integrated. In the previous paragraph we focused on Web services used 
to expose functionality of IT infrastructure elements. However, the same 
benefits of Web services can be leveraged by the management infrastructure, 
which is in itself a complex system composed of multiple parts, often 
provided by different vendors. Using Web services, it is possible to create a 
homogeneous layer that hides the differences provided by the various 
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management agents deployed on the IT systems and applications and that 
provides a uniform view to a management platform, thereby making it easier 
to monitor and control the underlying system in a holistic way. 

Although we believe that IT infrastructures as envisioned in this chapter 
will not be ready for a few years, many of the technological pieces are there 
today, and we hope that the discussions in this chapter will help clarify how 
these pieces fit together and therefore lay the conceptual foundations 
necessary to realize such a vision. 

The remainder of the chapter is structured as follows: we begin in 
Section 2 by presenting IT infrastructures as they are today. This will help us 
show the limitations of current technology in supporting the adaptive 
enterprise. Next, in Section 3, we present business scenarios that motivate 
the need for a business-oriented utility infrastructure. Section 4 discusses our 
vision for such an infrastructure and presents the technologies that can 
contribute to its realization. Finally, Section 5 makes some concluding 
remarks. 



2. STATE OF THE ART IN SERVICE DELIVERY 

This section presents a reference architecture of how companies view 
their IT infrastructure as multiple layers, and how they execute their business 
processes and deliver their services. Later in the chapter we will show why 
this architecture is, by itself, inadequate to support the adaptive, business- 
driven enterprise vision painted in here. The reference architecture is 
composed of essentially three layers, shown in Figure 1 and described in the 
following. 



2.1 Resource layer 

The lowest layer of the IT stack consists of the physical resources, and 
specifically servers, mainframes, networks, storage, and in general the 
hardware infrastructure. This layer can be structured and organized in 
different ways, depending on the needs of software applications (the next 
layer), on the anticipated workload of those applications, and on their 
performance requirements. 

Traditionally, a set of hardware resources is designed to be dedicated to 
each software application or to a group of software applications (e.g., 
databases, middleware, custom code, etc) that together support a delivered 
service Once the design decision was made, changes at the resource layer 
were rather infrequent. As we will see later in the chapter, having a dynamic 
resource layer, where resources can be assigned to services almost literally 
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on the fly to meet changing capacity needs is key to making the enterprise 
adaptive. If the resources are allocated once and for all, it is impossible to 
respond to business-driven adjustments and optimizations of IT 
infrastructure. 



Business process 
layer 



Application 

layer 



Resource 



Figure 1. Layers of a typical service delivery infrastructure 

Moreover, each department or business unit in charge of delivering the 
service was actually purchasing and managing the necessary hardware 
resources. This is also a problem in terms of cost of IT management, as each 
department is faced with the challenging task of managing complex IT 
systems, often resulting in less than optimal resource allocation with 
unnecessary duplication of hardware. Indeed, in recent years companies are 
aggressively trying to consolidate and centralize the location and 
management of the resources (either by physically co-locating them into a 
small number of large-scale data centers within the company or by 
outsourcing them altogether to IT firms such as HP, IBM, or EDS). 

2.2 Application layer 

This layer provides the software applications required for implementing 
the business processes (next layer above) in a company. It includes such 
applications as Database Management Systems (DBMSs), message brokers, 
application servers, enterprise software such as SAP and, in general, all 
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middleware applications. It also includes support for security, document 
management, directory management, and other features commonly needed 
by many applications. We also consider part of the application layer any 
custom business logic that has to be implemented on the top of middleware 
infrastructure in order to support the business processes. 

Most of these applications are used for implementing the day-to-day 
business processes in a company (e.g., financial accounting process) and are 
exposed to humans through user interfaces. Other applications are wrapped 
into “services” that can be invoked programmatically from other 
applications. The latter allow clients to be shielded from the actual 
implementation of the underlying application through a well-defined 
application programmer’s interface (API). Recently, technologies such as 
Web services are taking this approach a step further by standardizing the 
protocols necessary for such application-to-application interactions to 
happen over the Internet in a platform and programming language agnostic 
manner. This enables applications that are potentially running in multiple 
companies to interact with each other (e.g., an order processing application 
in one company can interact directly a supplier’s catalog application). 

Having a dedicated application infrastructure for each business process- 
as it is most often the case in today’s IT world - goes against the vision of 
the adaptive business-driven enterprise. In particular, it means higher costs 
in terms of software licenses and of management. Instead, companies would 
benefit from an IT environment in which the hardware and software 
infrastructure layers are to a large extent centrally managed, and where both 
of them can be deployed (installed and configured) in an adaptive fashion 
(quickly and automatically), to be able to meet requirements in response to 
dynamic changes. 

2.3 Business process layer 

The topmost layer in the IT infrastructure is composed of business 
processes , also called composite services in this context. These are complex 
services that are implemented by composing and invoking other services (we 
use the term service to denote an application that is invoked 
programmatically, as opposed to application used by humans through a GUI 
or a browser). 

As an example. Figure 2 shows a simple composite service that allows 
customers to order products. From the users’ perspective, a composite 
service is just like any other service: it has its own, defined, published 
interface (in this example, represented by one request/reply operation), and 
can be accessed in the same way any service can be accessed. What is then 
the point of considering composite services as belonging to a separate layer, 
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as opposed to "yet another" application? There are several reasons for this, 
some business-oriented and other technology-oriented. 

From a technology perspective, once composition techniques and tools 
are available, composition itself can be offered as a service. This means that 
users could leverage a composition service provided by the IT infrastructure 
to define new (composite) services on the fly and then use them. From a 
business perspective, this could mean that the user could not only create the 
composite service for "personal" use, but also act as the provider of this 
newly created service and offer it to other users, allowing a potentially 
unlimited number of players may join the IT infrastructure ecosystem. This 
is in contrast with what happens today, and constitutes a new business model 
for data center operators and IT companies, that can use the same 
infrastructure to serve the IT needs of different customers, thereby 
facilitating business process outsourcing. 

Another important aspect is that business processes are what enterprises 
care about. The goal for companies is to improve the quality and efficiency 
of their processes, as perceived by customers and by the providers 
themselves. Hence, the process is the place where the relevant business 
metrics are defined. Lower-level metrics, such as the response time of this or 
that application, are important only if they affect the value of business 
metrics. Improving on lower-level metrics is never the goal, rather they 
should be treated as symptoms and control points to understand and improve 
business process metrics. 



<receive> order 




Figure 2. A sample composite service 

In summary, the big challenges in this layer for realizing the adaptive 
enterprise vision are the ability to quickly create a new process from existing 
applications and services, the ability to translate the requirements on the 






Technologies for Business-Driven IT Management 



7 



business process into requirements on the layers below, and the ability to 
dynamically propagate the changes from one layer to the next. 



3. BUSINESS-DRIVEN MANAGEMENT OF IT 
INFRASTRUCTURE 

In this section we present a typical business-to-business order 
management scenario to be used as motivation for a sophisticated 
management infrastructure that spans through all the layers presented in 
section 2. Indeed, it is essential that these layers are coordinated and work 
together towards a common goal if we want to achieve the very ambitious 
goals of dramatically reducing the cost of IT management, of making the IT 
infrastructure adaptive to changes in the environment, and of aligning the IT 
environment with the business goals. 

3.1 Order management scenario 

The scenario we present models an enterprise that sells microprocessors 
to their business partners. We describe it in terms of the three layers 
identified in the previous section. 

3.1.1 Business process 

A sample order management process (composite service) is shown in 
Figure 3. On arrival of a new order, and after the new order has been 
validated (checked for completeness and consistency), the provider carries 
out a credit check and the order would be subject to block until the 
requester’s credit is vetted. Once the credit check phase has been carried out, 
scheduling takes place. The order is divided up into order lines (line items), 
which represent units of shipment. Depending on the inventory state on the 
provider side, some of the order lines are committed and the schedule of 
their delivery takes place. Some of the order lines may not be committed 
because of temporary inventory shortage. For each order line, an 
acknowledgement signal is sent back to the counterpart. At this point a 
delivery note is created and the fulfillment stage begins. 

3.1.2 Applications 

The order is transmitted through EDI (Electronic Data Interchange 31 ), 
which is the de facto standard for exchanging business documents (such as a 
purchase order, invoice, shipping schedule, inventory inquiry, and claim 
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submission) in a number of industries. The acknowledgment of commitment 
of order lines is also sent back to the requesting party through EDI. Most of 
the functionality needed for implementing this process can be supported by 
SAP application modules. SAP R/3 is used for order entry, incompletion 
hold, and for extracting relevant information from the order lines to create 
delivery notes. Delivery notes are created through a legacy application. 

Functionalities such as order validation, credit check, availability check, 
procurement, and fulfillment are also supported through SAP either through 
user interfaces (manually executed steps) or through Web service interfaces. 
In addition, the order management process requires middleware for process 
execution (such as service composition engines or workflow engines), Web 
services support software (such as HTTP servers and SOAP routers), and 
databases to store and log execution data. 



<receive> order 




Figure 3 . Order management process 



3.1.3 Resources 

A large number of resources are needed to support the order management 
process. Depending on the number of orders generated per day, one or more 
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front-end servers will be in charge of receiving users' requests. These servers 
will typically run HTTP servers. Other server machines and storage devices 
are needed for running application servers and the workflow engines, 
database servers, and the other applications. The overall number can range 
from a few units to, potentially, even hundreds of devices, as is the case for 
online stores such as Amazon. 

3.2 Reference architecture for management 

It is clear from the discussion so far that the only thing common across 
all IT systems is their complexity. This complexity arises from the size and 
scale of IT infrastructure in terms of number of resources, number of 
applications, number of processes, number of roles and players, number of 
configuration parameters, number of measurements to handle, number of 
corrective actions that can be taken, and the web of dependencies between 
all of the above. Business alignment and adaptability require changes in IT 
infrastructure in much shorter time scales than today, including in particular 
the coordinated changes to these parameters to improve business goals. 

The only way to deal with this complexity in a dynamic environment is 
to rely on automation. It is impossible to manually manage this complexity, 
both because of the number of factors involved in making decisions and 
because these decisions must sometimes be taken on the fly and enacted 
right away, and not offline. Hence, many of the operational tasks that are 
typically earned out by human operators need to be streamlined and 
automated. Automation is needed in all phases of the IT lifecycle - from 
provisioning to monitoring, decision making, and controlling - and in all 
layers of the stack. Besides enabling better management, automation also 
enables new opportunities. In particular, it allows the same data center to 
support multiple customers by reconfiguring the applications/processes 
executed on it, based on the business needs of the different service providers 
supported by the center itself, as well as its operator. 

Figure 4 shows a reference architecture for such a management system. It 
highlights the various functionalities that should be provided in the different 
stages of management lifecycle and across the layers of the IT stack. In the 
rest of this section, we will describe this reference architecture which we 
will use in the next section to position the various technologies that are being 
researched and developed today in the industry and academia. 

3.2.1 Provisioning 

The first set of management capabilities has to do with provisioning of IT 
systems. Provisioning deals with creation and deployment of business 
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processes right from identification of business-level requirements to the act 
of implementing, allocating, integrating, and configuring application and 
hardware resources in order to realize that business process. In section 2, we 
have discussed the need for better sharing of resources and the need to shift 
resources from one application to another on as-needed basis. In other 
words, we need automated provisioning capabilities that are driven by 
business policies and that use resources optimally. 

The provisioning phase also includes activities such as Service Level 
Agreement (SLA) and relative metric definition and negotiation if multiple 
parties are involved in implementing the business process (for e.g., data 
center operator, application service provider, business service provider, 
business process owner, and customers). All of these parties are typically 
linked by contractual relationships. For example, a database application 
service provider expects a certain availability of compute and storage 
resources from the data center. The business service provider expects a 
certain database transaction throughput from the application service 
provider, and the business process owner frames his/her SLA in even higher- 
level terms (e.g., number of purchase orders processed). It is essential that 
the management infrastructure allow service providers to model the SLAs 
they have stipulated. In addition to SLAs, service providers may want to 
define metrics that correspond to properties of interest to them, for example 
to evaluate the effectiveness with which a service is provided. For example, 
a frequently used metric involves the definition of the cost it takes to deliver 
a service to a customer. 

3.2.2 Monitoring 

The second set of capabilities needed by the management system is 
automated monitoring. This includes discovery of IT infrastructure elements, 
their dependencies, and how they affect each other and the overall business 
processes that they are part of. It also includes proper instrumentation of 
these elements, collection of the necessary data, and their aggregation to 
measure the metrics and SLAs that are of interest. While allowing the 
computation of higher-level metrics and SLAs, the technologies for 
monitoring should also facilitate drill-down into detailed measurements for 
problem resolution and root-cause analysis. 

The introduction of multiple players once again adds to the complexity of 
monitoring. When each of the players owns a portion of the IT infrastructure 
and collects data pertinent only to that portion, it becomes harder to compute 
aggregate metrics, to agree on the status of SLAs, or to assign blame in case 
of SLA violations. For example, consider the failure of a server owned and 
operated by a data center provider. If the applications hosted on that server 
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are owned by another service provider, then the failure may be attributed to a 
hardware failure (data center provider’s responsibility) or to an application 
error (service provider’s responsibility). 

3.2.3 Decision-making and control 

The third set of capabilities required in the management infrastructure is 
automated decision-making and closed-loop control. Being able to define 
and monitor metrics and SLA is only the first step towards the adaptive 
enterprise. To enable proactive management, it must be possible for users to 
analyze why metrics have unsatisfactory values (e.g., in which situations is 
an SLA not met). Understanding this can lead to a redesign of the business 
process, of the services, or to adjusting the resource needs. This can be 
typically done in conjunction with optimization techniques. While analysis 
and optimization enable off-line changes, prediction is at the hearth of the 
adaptive enterprise vision, since it enables dynamic change. In fact, the 
possibility of predicting the likelihood of a certain exceptional situation 
(such as an SLA violation) may lead to its prevention. 




Figure 4. Reference architecture for management 
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Predicting an exception only solves one side of the adaptive management 
problem. The other side requires techniques for managing the exception. Just 
like all aspects of the adaptive business-driven IT infrastructure presented 
here, exception handling also has to be driven by business goals. Indeed, the 
problem here consists in identifying what action to take, based on the 
predicted or detected problem, based on the perceived business damage that 
occurs if the problem is not corrected, and based on the cost of implementing 
the solution. 

Beyond the generic ability to detect, predict, and fix SLA violations, 
decision-making and control takes different forms when applied to different 
layers. In the resource layer, we need the ability to adjust resources allocated 
to applications in a dynamic and optimal manner. In the application layer, 
we need the ability to tune application parameters to meet business 
requirements. Finally, in the business process layer, we need the ability to 
re-design business processes if that is indeed the cause of a problem. 

3.2.4 Service-oriented architecture for management 

Finally, there are certain fundamental architectural principles that must 
be adhered to in creating this complex management infrastructure. There is 
clearly a danger of creating a large number of ad hoc management 
components that are tightly coupled in assembling such a management 
system. For example, one common mistake is to create a different 
management component for every different kind of resource, application, 
and business process. This, for instance, manifests in the form of several 
different languages for expressing SLAs, and different ways of interacting 
with resources and applications (based on their kind). Given the large 
number of possible kinds of elements in the IT stack, this will lead to a 
fragile and inflexible management system that is far less adaptive than the IT 
infrastructure it is used to manage. 

What we need is a structured approach to creating the management 
infrastructure based on standardized interfaces and service-oriented 
architectures. This allows management components across layers and 
functionalities to interoperate with each other easily, as all manageable 
components will adhere to the same framework and communicate through 
standardized protocols. This adds another dimension of requirements to the 
management infrastructure and is shown as a back plane in Figure 4. 
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4. TECHNOLOGIES FOR BUSINESS-DRIVEN IT 
MANAGEMENT 

In this section, for each of the three management functionalities domains 
identified in the previous section - provisioning, monitoring and control - 
we present a collection of technologies that are being developed in the 
academia and in the industry and fit them in the map that we began 
sketching in the previous section. 

4.1 Technologies for provisioning 

4.1.1 Virtualization 

As discussed earlier, resources and applications are traditionally allocated 
in a dedicated manner. The amount of resources to be allocated is decided 
either based on peak demands (the result of which is poor average 
utilization) or based on average demands (the result of which is inability to 
cope with fluctuations in demand). In either case, dedicated resources imply 
high equipment/license costs. In many cases, application demands cannot be 
predicted in advance and having dedicated infrastructure decreases the 
flexibility of shifting resources from a low-priority application to a high- 
priority one. Utility computing presents a paradigm where shared 
infrastructure can be provided on demand to multiple applications. 

Virtualization is the primary enabler of utility computing. It is a set of 
transformation processes that make one set of “underlying” resources with 
some capabilities look like another set of “virtualized” resources with 
different capabilities. For example, a server with a certain number of CPUs 
and physical memory can be virtualized into several virtual machines 
(VMs), with each of them having a subset of the CPUs and physical 
memory. Virtualization ensures the isolation between the VMs and provides 
the illusion that each of the VMs is a complete server. 

Virtualization, as described here, is not a new technology. Virtual 
memory in machines provides application processes with the impression of 
using larger memory than is actually available. Virtual disks of RAID arrays 
provide the impression of faster and more reliable disks than physical disk 
devices. Network virtualization allows to fully decouple sub-networks used 
by different applications from one another by providing individual IP 
address spaces. 

Although virtualization by itself is not a new technology, its use in a 
commercial data center environment to provide more agility to enterprise IT 
is new. Recent developments in virtualization technologies are providing 
better security isolation (completely hiding one virtualized entity from 
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another) and performance isolation (minimizing the performance impact one 
entity has on another), which are essential in a data center. Server 
virtualization technologies such as VMWare 32 and Xen 4 , network 
virtualization through VLANs, and storage virtualization through Storage 
Area Networks (SANs) are being applied to achieve the goals of flexibly 
sharing physical resources and adjusting those shares on the fly. Similar 
notions of virtualization are also being thought of at the application layer 30 . 

The programmability and isolation provided by virtualization 
technologies such as the ones described above are critical for utility 
computing - in order to allocate resources on demand and in order to shift 
resources from one application to another dynamically. 

4.1.2 Utility data centers and Grids 

To address the problems associated with high costs of owning and 
operating IT infrastructures, companies are trying to consolidate their 
physical and application resources into data centers. Such consolidation 
typically involves: 

□ Co-location of resources (as opposed to distribution of resources across 
all departments in a company), 

□ Creation of structured and manageable physical topologies (as opposed 
to ad hoc networks that evolve over time in a decentralized 
environment), 

□ Use of a single or a small number of vendors for all the physical and 
application resources (as opposed to largely heterogeneous resources 
from different vendors and with different versions that builds up in an 
uncontrolled environment), 

□ Co-location of human expertise for providing support and services on 
the infrastructure (as opposed to multiple sets of consultants that are 
hired by each department), and 

□ Sharing of physical and application resources through virtualization as 
explained above. 

If the data center also supports utility computing by allowing resources to 
be shared and adjusted dynamically, then it is called a Utility Data Center. 
HP’s Utility Data Center (UDC) 17 is the first among such data centers to 
offer a fully virtualized server, network, and storage environment. 
Applications can programmatically request a securely isolated ‘farm’ to be 
carved out of the UDC resources. A farm in UDC is a set of servers, 
connections, and storage connected in a particular topology (e.g., 3-tier 
topology, cluster topology, etc). The UDC selects the best unused resources 
that satisfy the application’s requirements, and configures them to create the 
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illusion of the farm. It does so by configuring the VLANs on network 
switches and the SANs on storage switches. 

In order to adapt to application’s changing workloads, HP’s UDC also 
supports dynamic flexing of resources. An application can request that 
additional resources be added to the farm or that existing resources be 
removed without affecting running applications. This capability increases 
the ability of IT infrastructure to react to business changes such as increase 
in customers, creation of a new service, or the rolling out of a new 
promotion. 

There are other efforts that are aimed at providing similar programmatic 
access to resources when needed. Popular among these are the 
Computational Grids , which are large clusters of thousands of servers 
distributed across universities, super computer centers, and research 
organizations around the world. These Grids are commonly used by 
companies, government organizations, and academia for large scientific 
computations such as weather forecasting, simulations, and bio-medical 
applications. More recently, the concept of Data Grids 11 has also been 
gaining popularity, where the focus is on having a large pool of data stores 
as opposed to compute servers. The core technology behind these Grids is a 
set of protocols for discovering, requesting, using, and releasing resources, 
and job scheduling. Examples of these Grids include West Grid 33 and NASA 
Information Power Grid 22 . 

4.1.3 Resource allocation 

While virtualization provides the underlying mechanism for resource 
sharing, the intelligence for how many resources to allocate for each 
application and the choice of application mix to place on a particular 
resource is resident in resource management systems. 

There are several factors to be considered for proper resource allocation. 
First, the constraints imposed by the application or process demanding those 
resources must be satisfied. Examples of such constraints include the time 
periods when the resources are required, the quality of service guarantees to 
be obeyed, and the number and type of resources required. Second, the affect 
of allocating an application on existing applications must be considered. 
Certain applications exhibit peak workloads at the same time. Co-allocating 
such applications on to the same resource may result in performance 
problems. Third, priorities and business policies must be taken into account 
while making trade-offs. For instance, if there is not enough capacity, then 
resources should be moved from a lower-priority application to a higher- 
priority one. 
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Many technologies are being developed to simplify and automate 
resource allocation. Market-based allocation schemes such as resource 
auctions are being used to automate fair allocation of resources based on 
business priorities. As the name suggests, market-based resource allocation 
is based on designing a market for allocating the available IT resources to 
the entities responsible for running the applications and the business process 
on top of them. These entities bid in this market to make sure that the portion 
of the IT infrastructure that is made available to them meets their business 
objectives. Naturally the metaphor of the market works at its best when there 
are multiple parties involved, as in some of the scenarios described above, 
but it’s equally applicable when the agents bidding in the market all 
cooperate and are bidding to represent the only party that has interest in the 
market. Although market-based resource allocation has not yet reached the 
level of maturity for successful industrial deployment, system based on this 
paradigm have been investigated in the academic literature, see for example 
Wolski et al . 34 where market-based resource allocation is investigated in a 
Grid setting. 

Mathematical optimization techniques 36 and workload characterization 
techniques 27 are also being used for optimal or near-optimal placement of 
applications onto resources. These techniques rely on a deep understanding 
of the physical infrastructure, application workload characterization, and the 
impact of those workloads on the resource requirements. Simulation and 
correlation techniques 13 are useful in inferring how resource requirements 
change with changing workloads. 

Another aspect of utility computing is to simplify installation and 
configuration of applications once resources are allocated to them. 
Workflow and scripting technologies for orchestrating and managing various 
configuration activities and languages for specifying such configurations and 
workflows 16 are being researched in this regard. 

4.2 Technologies for Monitoring 

4.2.1 Data integration 

Once a business process is operational, there are a number of 
instrumentation sources that are activated in order to collect various kinds of 
data from the applications and resources that implement that process. This is 
required to validate whether the objectives of the process are being met, 
whether there are any improvements that need to be made in the future, or 
simplify to detect unforeseen conditions and bugs. 

Given that a number of business processes, applications, and resources 
make up any given IT infrastructure, the amount of data collected from these 
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sources becomes quickly unmanageable. But, an even more significant 
problem is the ability to integrate data from all the data sources. This arises 
because of the lack of agreement on structure or semantics of the provided 
data. For instance, servers in the physical resource layer produce data about 
CPU utilizations, memory utilizations, and failures in hardware. 
Applications such as databases produce instrumentation data such as number 
of queries serviced per second, performance problems, and SQL errors. 
Business processes, on the other hand, can be instrumented to provide data 
about number of orders processed (considering an order processing process, 
for instance) or the number of orders that did not go through. Often there are 
no relationships between these individual pieces of data to enable 
correlation. 

Even within the physical resource layer, not all servers provide their data 
(e.g., CPU utilizations) in the same format. This changes from vendor to 
vendor and largely depends on the kind of instrumentation used. For 
instance, some may report CPU utilizations averaged over 5 minute 
intervals, while others do that for 10 minute intervals. Similarly, the 
structure and types of events reported by every element in the IT stack are 
different. 

These problems make it very hard to build automated tools that can 
understand, analyze, and predict problems in IT infrastructure. There are 
some efforts aimed at standardizing the semantics behind the data collected 
from various sources. Examples of these standards include the Common 
Information Model (CIM) 12 , Application Response Measurement (ARM) 29 
and, more at the business level, SCOR measures 28 . However, these standards 
are confined to a certain aspect of the IT infrastructure, and are not designed 
to work together. This is part of the reason why there is today no end to end 
management solution. 

4.2.2 Metric definition and monitoring 

Most modem applications provide a way for users or other programs to 
access monitoring information. For example, operating systems offer access 
to a variety of statistics and real time information about processor and 
memory usage, network management applications provide information on 
network load, while process management applications provide such 
information as the number of processes executed and the average duration of 
each process. 

All this is very useful, and has greatly improved the manageability of 
such applications. However, it is not sufficient to realize the vision set forth 
in this chapter. There are two aspects that are missing in this picture: 




18 



1. Predefined metrics are not sufficient to model business goals, which is 
what we ultimately want to optimize. For example, a process 
management software may offer metrics such as the average duration of 
each step, but users may be more interested in modeling an SLA on top 
of a process, that may for example require that orders of a certain 
product and below a certain volume be delivered within 5 days. This is 
something that is not provided out of the box, but that can in principle be 
measured since all the information is known and logged by the process 
management system. Hence, analysts must be provided with a way for 
defining and monitoring metrics 

2. Each application has its own format for storing metric data, and its own 
protocol for communicating this information. This makes it extremely 
difficult for a management system to collect and correlate information at 
the different layers of the stack and use this information in a coordinated 
fashion to determine causes of unsatisfactory metric values and 
determine the root causes. This problem is analogous to the data 
integration one mentioned above. To achieve the vision set forth in this 
chapter, a uniform metric model and a uniform protocol to access metric 
values is needed. 

Although these are fairly new requirements, there are already some 
proposals that try to fill these needs. The first issue is being addressed by 
several proposals that aim at providing easy-to-use metric models, so that 
analysts can specify new metrics in addition to the built-in ones 8, 20 The 
underlying principle of all these approaches is that a certain set of logical 
"measurement devices" are provided to the user, which can be customized 
and combined in several ways for defining metrics and how they should be 
computed . For example, a "measurement device" could provide the time 
distance between two steps A and B in a process. This can be used to model 
an SLA on the order management process that says that the time interval 
between the order receipt (step A in this case) and the confirmation sent to 
the customer (step B) should be kept below a certain threshold. Other 
examples of such logical devices are those returning the value of a process 
variable or the duration of a step. In this way, the metric definition can be 
made rather simple as it only requires instantiating the logical devices. It is 
up to the application provider to implement these devices. For example, the 
process engine will implement the (parametric) business logic that returns 
the time distance between two steps, and offer this device for use within 
metric definition. 

The second issue is addressed by Web service technology, which is a 
strong candidate for masking heterogeneity and for providing homogeneous 
access to heterogeneous systems (in this case, to heterogeneous application 
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monitoring systems). We do not comment further on the use on Web 
services since we will discuss this issue later in the chapter. 

4.3 Technologies for decision making and control 

Monitoring is useful per se, but its greatest value is when it is combined 
with analysis and optimization. The goal here is to take the outcome of the 
monitoring system and use it to identify problems (again, expressed in terms 
of business metrics) and make changes to the system to remove such 
problems. The challenge, again, lies in how to do this automatically and 
without requiring ad hoc solutions for each metric or each system. 

4.3.1 Business process analysis and optimization 

Analysis and optimization of business processes has been traditionally 
based on simple techniques that show simple statistics of process execution 
data in tabular or chart form. As people started to realize the importance of 
process analysis, tools became more sophisticated and were extended with 
warehousing mechanisms and OLAP analysis. While applying OLAP to 
process data is certainly helpful, it is insufficient to provide explanations of 
why certain metrics have certain values (e.g., unsatisfactory values) and to 
predict future values, which are the two things users care about. To perform 
this kind of '’intelligent" analysis, data mining technologies are being put to 
use. 

Data mining techniques are being applied to understand patterns that lead 
to poor quality workflow or service executions, and as a result, to identify 
areas for improvements. For instance, the problem of analyzing why a metric 
has a certain value can be mapped to a classification problem. Classification 
applications take as input a labeled training data set (typically in the form of 
a relational table) in which each row (tuple) describes an object (e.g., a 
customer in a customer management application, or a process execution in 
our case) and the class to which this object to be classified belongs (e.g., 
“profitable”, “neutral”, or “unprofitable” customer). The classifier then 
produces a set of classification rules , i.e., mappings from a condition on the 
objects' attributes to a class, with the meaning that objects whose attributes 
satisfy the condition belong to the specified class. Therefore, classification 
rules identify the characteristics of the objects in each class, in terms of 
values of the objects' attributes 5 . 

This approach provides many benefits: first, it allows intelligent analysis 
and prediction of metrics at the business process level. Second, if application 
and resource information are included among the factors considered by the 
classifier, then it is possible to assess the impact that resource and 
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application characteristics have on business metrics. For example, we can 
see that whenever a certain low-power resource executes a process, then a 
certain SLA. This information can be used to drive resource and application 
requirements down from business metric. Third, this approach is metric- and 
process-independent, and is therefore generally applicable. 

4.3.2 Application tuning 

Service level objectives as well as results coming from process analysis 
(either performed through data mining, or through more traditional means 
such as "simple” metric definition and management technology) can be used 
to better tune applications and size systems. 

Most applications, especially server applications, include a number of 
parameters that need to be set appropriately for the application to operate in 
the "best" possible way from the perspective of meeting business goals, and 
can work in many different configurations. For example, databases can be 
supported by a single machine, or can run on parallel computers. 
Furthermore, a DBMS can be set in many different ways based on the 
requirements of the service using it. For example, administrators could select 
different logging and data archival mechanisms, based on the data recovery 
needs. 

There are essentially two ways in which one can do application tuning 
and sizing: a priori and a posteriori. The a priori approach is based on known 
mappings between service level objectives and application parameters. For 
example, well-known benchmarks can be used (or extrapolated) to determine 
how to configure a database or how many servers should be used to run the 
database. This mapping is done manually today, but there are approaches 
that are aimed at automating this. 

The a posteriori approach is a form of closed-loop management, where 
service execution metrics are evaluated and used to change the application 
characteristics. Control theory approaches 26 , or data mining techniques like 
those described in the earlier section are being used to dynamically adjust 
web server, application server, and database parameters. This being said, 
achieving automation in application tuning is still a challenging problem as 
most of the existing techniques are very specific to the application they 
manage and are not yet effective under all workloads. We expect this to be 
one of the most interesting and tough research topics over the next few 
years. 
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4.4 Technologies for service-oriented architectures 

4.4.1 Web services 

The term Web services is used to refer to applications that are accessible 
programmatically using Web technologies 1 . Web services technology 
comprises of languages and infrastructure that enables users to: 

□ Describe the interface, behavior, and possibly other non-functional 
aspects of services. Examples of such description languages are 
WSDL 10 , enabling the description of the service interface, and BPEL 3 
and WSCI 2 , that allow the description of the order in which the different 
service methods should be invoked to achieve a certain goal. 

□ Publish service description information on private or public registries, to 
enable static service discovery or dynamic binding. Examples of service 
registries are provided in UDDI 24 and ebXML 23 . 

□ Achieve interoperability among services, by providing and supporting 
standardized interaction protocols. Examples of such protocols are 
SOAP 14 , supporting basic interaction by prescribing how information 
should be packaged into XML documents, WS-ReliableMessaging 6 , 
introducing a protocol for achieving reliable information exchange, or 
WS-Transactions 7 , defining how a set of interactions can be given 
transactional semantics. 

The reader will notice that, from what is described above, Web services 
do not appear to be fundamentally different from services in conventional 
middleware, such as CORBA or COM objects. Indeed, description 
languages, registries, and interaction protocols were also available and 
successfully used in earlier middleware platforms, before the advent of Web 
services. However, Web services and the related technologies have been 
designed to operate in a B2B context. This fact implies important differences 
in how the interaction takes place: firsts, there is no obvious place where to 
put the middleware. In intra-organizational interaction, many middleware 
components (such as the TP monitor or the message broker) were 
conceptually centralized and managed. In B2B interactions there is no 
centrally managed component, and the interaction must occur in a fully 
distributed fashion. 

In turn, this means that standardizations become essential: while with a 
central middleware it is the middleware itself that imposes certain 
description languages or interaction protocols, in B2B the different parties 
(that will likely use different middleware platforms) will need to agree on 
common interchange formats and interaction protocols. Unless such formats 
and protocols are standardized, it is very costly, not to say unfeasible, for a 
company to maintain interactions with several business partners. Finally, 
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decentralization also means that B2B protocols, besides being standardized, 
need to be designed to work in a distributed fashion and in the absence of a 
central coordinator. In those cases where a central coordinator is required, 
then protocols are needed for the only purpose of defining who the protocol 
coordinator is. 

4.4.2 Web services for management 

The reason we talk about Web services in this chapter is that they are 
very relevant to the management of utility infrastructure. In fact, the 
discussion above has emphasized that Web services reduce heterogeneity. 
Thanks to standardization, they make it possible to access very disparate 
applications and resources by using the same set of protocols and data 
interchange formats. From a management perspective, this means that in the 
near future both applications and management agents will provide a Web 
service interface to allow their management. This considerably simplifies the 
development of an overall management platform, which can use the same 
technology to gather monitoring information and control heterogeneous set 
of software and hardware resources. 

In the service-oriented paradigm, there are certain patterns of interaction 
that are essential to the successful operation of the environment. These 
interactions establish and ensure that services adhere to acceptable 
guidelines of behavior when they interact. Without these guarantees, the 
service-oriented approach becomes chaotic and incomprehensible leading to 
unreliable performance, and unsubstantiated finger pointing when failures 
occur. In general, the following four interactions as essential: 

1. Negotiation is the process by which services interact to set-up guidelines 
prior to other interactions. Negotiation permits a wide set of parameters 
to be established, and it permits a multi-phase process of offers and 
counter offers that result in the services working together to form an 
agreement that governs further interactions. 

2. Monitoring occurs during the operation of the services. Measurements 
are taken and aggregated, and can be compared to agreed upon 
guidelines or other requirements specified by administrators. 

3. Control refers to the ability to make changes to a service’s 
characteristics. Often, the goal is to bring it back in-line with agreed 
upon parameters if they should fall out of bounds during operation. 

4. Renegotiation is a re-running of the negotiation process after service 
interactions have begun. It can be used, for example, when no control 
operations are possible, and a service or administrator determines that 
the existing agreement can no longer be satisfied, so an updated one is 
needed. 
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One concerted effort that is aimed at applying Web services to 
standardize these kinds of interaction patterns is WS-Resource Framework 
(WSRF) 25 . For example, WS- Agreement 35 , which is a part of WSRF, defines 
a new approach for interactions between a service provider and its 
consumers. In most present systems, the conditions under which a service is 
provided are either left completely open (usually resulting in “best effort”), 
are specified out-of-band with the service (for example, a contractual 
engagement specifying a consumer as having “gold-level” service), or are 
handled as invocations on the service itself (in the utility model, this is 
equivalent to requesting resources without prior assurance that they will be 
available). In contrast, WS- Agreement makes the statement and negotiation 
of these “terms of service” explicit. Making these explicit has the benefit of 
setting expectations for both the service consumer and provider, and can 
provide specific metrics that can be monitored during operation. Another 
similar effort - attempting to standardize interactions for monitoring 
resources and applications - is ongoing in OASIS, and is called Web services 
management framework (WSMF) 9 . 

4.4.3 Agent technology 

Software agents are defined as software artifacts that act autonomously to 
undertake tasks on behalf of users 19 . An agent-based approach to software 
development allows an analyst - or more in general the agent’s stakeholders 
- to declaratively specify the agent’s goals instead of issuing explicit 
instructions, leaving to the agent the decisions on how to best accomplish 
such goals. 

The academic literature is rich with applications of both autonomous 
agents and multi agent systems to management problems at all levels, 
ranging from intrusion detection at the resource level to transforming 
infrastructure data into real-time business intelligence, for managing at the 
higher level of the stack. Market-based resource allocation that we have 
covered in one previous section can itself be seen as an example of a multi- 
agent system to solve the dynamic resource reallocation problem. In some 
notable cases, agent-based solutions to management problems have been 
adopted in the industry as well. HP Openview features agent-based solutions 
to storage area network configuration and monitoring and security 
management among others, and so do other leading management software 
vendors such as IBM, BMC, and Micromuse. 

In addition, because of the declarative nature of the goal directed 
approach, agent-based solutions are well suited to tackle the problem of 
service composition that we exposed when presenting the business process 
layer of our conceptual architecture. See Maamar et al . 21 for an example of 
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an agent-based architecture to interleave web services composition and 
execution. 

4.5 Realizing the management infrastructure 

This section discusses the different ways of realizing the adaptive 
management infrastructure. We study the alternatives along different 
dimensions. In many cases, each of the alternatives presents a valid solution 
and differs from the other alternatives only in the approach taken to reach 
the end goal. 

4.5.1 Off-line versus online 

The management system may operate in an off-line or on-line fashion, 
and different technologies may be better suited for one or the other mode of 
operation. In off-line management, the goal is to structure or correct the 
system either before starting to provide the service or periodically during 
down times. Online management refers instead to changes and fine-tuning of 
the IT infrastructure to respond to a predicted or detected exceptional 
situation or in general to improve the quality of each individual service being 
delivered to a customer. Online management pushes the notion of adaptive 
enterprise to its limit, as the IT infrastructure and the allocation of resources 
to services and business processes is changed on the fly, to meet the need of 
each service and process execution. As closed-loop control techniques 
mature and as the level of trust that operators have in these increases, on-line 
techniques will be used more and more. 

4.5.2 A priori versus a posteriori 

Technologies for optimal resource allocation and process and service 
optimization can be characterized based on the kind of information and 
technique they use for determining how to improve the process. A priori 
approaches start from a model of the processes, services, and resources, as 
well as of the estimated load on the system Based on the model, these 
approaches derive the requirements necessary to satisfy the desired business 
goals, either through mathematical analysis or through simulation. For this 
reason, they are also called model-based approaches. 

A posteriori approaches treat the system as a black box, and try to infer 
its behavior by looking at execution data. Specifically, these approaches try 
to correlate observable parameters of the system (at all levels, ranging from 
business data exchanged with customers to resource utilization data) with 
business-relevant metrics, and based on this they perform sensitivity analysis 
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(identify how variability in a parameter can affect the metric). The most 
classical examples of a posteriori approaches are those based on statistical 
analysis and on data mining. 

There is a tension between these two options since a very good model 
that takes into account a number of anticipated scenarios decreases the need 
for a sophisticated a posteriori system. On the other hand, a very powerful a 
posteriori technique can do fine despite a poor initial model, since the 
control-loop anyway adjusts and adapts to changes. In general, a 
management infrastructure needs both sets of technologies - the former to be 
used in the case of lack of availability of execution data and the latter to 
validate the former. 

4.5.3 Local versus global management 

Another dimension of the management problem is related to the layers to 
which the technology can be applied and to whether the management 
platform performs the control and optimizations separately on the different 
layers or considers all layers in a holistic fashion. 

In general, today the technologies that we discussed are applied (if at all) 
on only one layer. However, we believe that the vision of the adaptive 
enterprise requires both the application of these technologies to all layers 
and the use of the results to collectively manage all the layers in order to 
optimize business goals. 



5. CONCLUSION 

This chapter has presented a framework and a vision that enable the 
automated management of an enterprise’s IT infrastructure so that it is 
aligned with business goals and is able to adapt to changes in the business 
and IT environment to keep the IT at the service of the business. We have 
motivated why there is an increasing need for such an alignment, why 
current IT infrastructures are far away from achieving this ambitious 
objective, what are the challenges that need to be addressed to get there, and 
which are the technologies that can help companies meet these challenges. 

In particular, we believe that the recipe for adaptive business-driven 
management is based on the basic architectural principle of service 
orientation and on few key technological ingredients such as resource 
virtualization, standardized metric definition and integration, and 
optimization driven by data mining. These technologies, along with the other 
presented in the chapter, constitute the basic tools that are needed to build a 
management system that spans across all the layers of the IT infrastructure 
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and that is able to translate business goals into requirements at the IT 
(resource) level. Many IT vendors are already going in the direction of 
integrating these technologies to achieve adaptive management, but current 
solutions are still far away from the vision painted in this chapter: they either 
focus on specific layers of the IT stacks (or even specific applications) or 
they cover the whole stack, but only through ad hoc solutions and long 
deployment efforts. 

The reader will have observed that we placed little emphasis on 
techniques geared towards automatically modifying a business process. The 
research on automated process modification is still in the very early stages, 
and while users may be comfortable with an automated system managing 
minor application configuration details or load balancing strategies, altering 
a business process on the fly is something that few IT managers would 
allow. However, we believe that as management technology mature, and as 
process models are extended with "hooks" that enable a controlled form of 
closed-loop management, automated process evolution will also become a 
reality. 
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Abstract Service-Oriented Computing (SOC) is the computing paradigm that utilizes ser- 
vices as fundamental elements for developing applications/solutions. To build the 
service model, SOC relies on the Service Oriented Architecture (SOA), which is 
a way of reorganizing software applications and infrastructure into a set of inter- 
acting services. However, the basic SOA does not address overarching concerns 
such as management, service orchestration, service transaction management and 
coordination, security, and other concerns that apply to all components in a ser- 
vices architecture. 

In this paper we introduce an Extended Service Oriented Architecture that 
provides separate tiers for composing and coordinating services and for managing 
services in an open marketplace by employing grid services and discuss how agent 
technology can be used to support the functions of the Extended SOA. 



1. INTRODUCTION 

Service-Oriented Computing (SOC) is the computing paradigm that uti- 
lizes services as fundamental elements for developing applications-solutions. 
Services are self-describing, platform-agnostic computational elements that 
support rapid, low-cost composition of distributed applications. Services 
perform functions, which can be anything from simple requests to com- 
plicated business processes. Services allow organizations to expose their 
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core competencies programmatically over the Internet (or intra-net) using 
standard (XML-based) languages and protocols, and implemented via a 
self-describing interface based on open standards. 

Because services provide a uniform and ubiquitous information distrib- 
utor for a wide range of computing devices (such as handheld comput- 
ers, PDAs, cellular telephones, or appliances) and software platforms (e.g., 
UNIX or Windows), they constitute the next major step in distributed com- 
puting. 

Services are offered by service providers — organizations that procure 
the service implementations, supply their service descriptions, and pro- 
vide related technical and business support. Since services may be offered 
by different enterprises and communicate over the Internet, they provide 
a distributed computing infrastructure for both intra- and cross-enterprise 
application integration and collaboration. Clients of services can be other 
solutions or applications within an enterprise or clients outside the enter- 
prise, whether these are external applications, processes or customers/users. 
To satisfy these requirements, services should be technology neutral in that 
the invocation mechanisms (protocols, descriptions and discovery mech- 
anisms) should comply with widely accepted standards. Services should 
also be loosely coupled as they must not require knowledge or any inter- 
nal structures or conventions (context) at the client or service side. Finally 
services should support location transparency. Services should have their 
definitions and location information stored in a repository — e.g. based on 
UDDI — and be accessible by a variety of clients that can locate and invoke 
the services irrespective of their location. 

Services come in two flavors: simple (stateful services) and composite 
services (stateless services). The unit of reuse with services is functionality 
that is in place and readily available and deployable as services that are capa- 
ble of being managed to achieve the required level of service quality. Com- 
posite services involve assembling existing services that access and combine 
information and functions from possibly multiple service providers. For ex- 
ample, consider a collection of simple services that accomplish a specific 
business task, such as order tracking, order billing, and customer relation- 
ships management. An enterprise may offer a composite Web service that 
composes these services together to create a distributed e-business applica- 
tion that provides customized ordering, customer support, and billing for a 
specialized product line (e.g., telecommunication equipment, medical in- 
surance, etc). Accordingly, services help integrate applications that were 
not written with the intent to be easily integrated with other distributed ap- 
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plications and define architectures and techniques to build new functionality 
while integrating existing application functionality. 

Service-based applications are developed as independent sets of interact- 
ing services offering well-defined interfaces to their potential users. This is 
achieved without the necessity for tight coupling of distributed applications 
between transacting partners, nor does it require pre-determined agreements 
to be put into place before the use of an offered service is allowed. 

While the services encapsulate the business functionality, some form of 
inter-service infrastructure is required to facilitate service interactions and 
communication. Different forms of this infrastructure are possible because 
services may be implemented on a single machine, distributed across a set of 
computers on a local area network, or distributed more widely across several 
wide area networks. A particularly interesting case is when the services use 
the Internet as the communication medium and open Internet-based stan- 
dards. A Web service is a specific kind of service that is identified by a URI 
and exhibits the following characteristics. It exposes its features program- 
matically over the Internet using standard languages and protocols, and it 
can be implemented via a self-describing interface based on open standards 
(e.g., XML interfaces which are published in network-based repositories). 

Interactions of Web services occur as SOAP calls carrying XML data 
content and the service descriptions of the Web services are expressed using 
WSDL (20) as the common (XML-based) standard. WSDL is used to 
publish a Web service in terms of its ports (addresses implementing this 
service), port types (the abstract definition of operations and exchanges 
of messages), and bindings (the concrete definition of which packaging 
and transportation protocols such as SOAP are used to inter-connect two 
conversing end points). The UDDI (19) standard is a directory service 
that contains service publications and enables Web service clients to locate 
candidate services and discover their details. 

Web services share the characteristics of more general services, but they 
require special consideration as a result of using a public, insecure, low- 
fidelity mechanism for inter-service interactions. 

This paper is organized as follows. In Section 2 we introduce the concept 
of software as a service, while in Section 3 we describe the basic service 
oriented architecture. Section 4 describes an extended service architecture 
materialized by grid services and Section 5 introduces the concept of service 
bus for open service marketplaces. Section 6 is devoted to agent-oriented 
technology and how it can be used to support the service-oriented computing 
vision. Finally, Section 7 presents our conclusions. 
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2. A VIEW OF SOFTWARE AS A SERVICE 

The concept of software-as-a-service espoused by SOC is revolutionary 
and appeared first with the ASP (Applications Service Provider) software 
model. An ASP is a third party entity that deploys, hosts and manages 
access to a packaged application and delivers software-based services and 
solutions to customers across a wide area network from a central data center. 
Applications are delivered over networks on a subscription or rental basis. 
In essence, ASPs were a way for companies to outsource some or all aspects 
of their information technology needs. 

By providing a centrally hosted Internet application, the ASP takes pri- 
mary responsibility for managing the software application on its infras- 
tructure, using the Internet as the conduit between each customer and the 
primary software application. What this means for an enterprise is that the 
ASP maintains the application, the associated infrastructure, and the cus- 
tomer’s data and ensures that the systems and data are available whenever 
needed. 

Although the ASP model introduced the concept of software-as-a-service 
first, it suffered from several inherent limitations such as the inability to 
develop highly interactive applications, inability to provide complete cus- 
tomizable applications (8). This resulted in monolithic architectures, highly 
fragile, customer-specific, non-reusable integration of applications based 
on tight coupling principles. Today we are in the midst of another sig- 
nificant development in the evolution of software-as-a-service architected 
for loosely-coupled asynchronous interactions; this is based on XML stan- 
dards with the intention of making access to and communications between 
applications over the Internet easier. 

The SOC paradigm allows the software-as-a-service concept to expand 
to include the delivery of complex business processes and transactions as 
a service, while permitting applications to be constructed on the fly and 
services to be reused everywhere and by anybody. Perceiving the relative 
benefits of (Web) services technology many ASPs are modifying their tech- 
nical infrastructures and business models to be more akin to those of Web 
service providers. 



3. THE BASIC SERVICE ORIENTED 
ARCHITECTURE 

To build integration-ready applications the service model relies on the 
Service-Oriented Architecture (SOA). SOA is a way of reorganizing a port- 
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folio of previously siloed software applications and support infrastructure 
into an interconnected set of services, each accessible through standard 
interfaces and messaging protocols. Once all the elements of an enter- 
prise architecture are in place, existing and future applications can access 
these services as necessary without the need of convoluted point-to-point 
solutions based on inscrutable proprietary protocols. This architectural ap- 
proach is particularly applicable when multiple applications running on 
varied technologies and platforms need to communicate with each other. 
In this way, enterprises can mix and match services to perform business 
transactions with minimal effort. 
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Figure 2. 1. The basic Service Oriented Architecture. 



SOA is a logical way of designing a software system to provide services 
to either end-user applications or other services distributed in a network 
through published and discoverable interfaces. The basic SOA defines an in- 
teraction between software agents as an exchange of messages between ser- 
vice requesters (clients) and service providers. Clients are software agents 
that request the execution of a service. Providers are software agents that 
provide the service. Agents can be simultaneously both service clients and 
providers. Providers are responsible for publishing a description of the ser- 
vice^) they provide. Clients must be able to find the description(s) of the 
services they require and must be able to bind to them. We examine the use 
of software agents in Section 6. 
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The basic SOA is an architecture not only about services, it is also a 
relationship between three kinds of participants: the service provider , the 
service discovery agency, and the service requestor (client). The interac- 
tions involve the publish, find and bind operations (3); see Figure 2.1 . These 
roles and operations act upon the service artifacts: the service description 
and the service implementation. In a typical service-based scenario a service 
provider hosts a network accessible software module (an implementation 
of a given service). The service provider defines a service description of 
the service and publishes it to a client or service discovery agency through 
which a service description is published and made discoverable. The service 
requestor uses a find operation to retrieve the service description typically 
from the discovery agency, i.e., a registry or UDDI repository, and uses the 
service description to bind with the service provider and invoke the service 
or interact with service implementation. Service provider and service re- 
questor roles are logical constructs and a service may exhibit characteristics 
of both. 

The fundamental logical view of a service in the basic SOA is that it is a 
service interface and implementation. A service is usually a business func- 
tion implemented in software, wrapped with a formal documented interface 
that is well known, and known where to be found not only by agents who 
designed the service but also by agents who do not know about how the 
service has been designed and yet want to access and use it. Services are 
intended to represent meaningful business functionality that can be assem- 
bled into larger and new configurations depending on the needs of particular 
kinds of users. 

The interface simply provides the mechanism by which services com- 
municate with applications and other services. Technically, the service 
interface is the description of the signatures of a set of operations that are 
available to the service client for invocation. The service specification must 
explicitly describe all the interfaces that a client of this service expects as 
well as the service interfaces that must be provided by the environment 
into which the service is assembled/composed. As service interfaces of 
composed services are provided by other (possibly singular) services, the 
service specification serves as a means to define how a composite service 
interface can be related to the interfaces of the imported services and how 
it can be implemented out of imported service interfaces. This is shown in 
Figure 2. In this sense, the service specification has a mission identical to 
a composition meta-model that provides a description of how the Web ser- 
vice interfaces interact with each other and how to define a new Web service 
interface (<PrortType>) as a collection (assembly) of existing ones (im- 
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ported <PrortType>s); see Figure 2.2. A service specification, thus, defines 
the encapsulation boundary of a service, and consequently determines the 
granularity of replaceability of Web service interface compositions. This 
is the only way to design services reliably using imported services without 
knowledge of their implementations. As service development requires that 
we deal with multiple imported service interfaces it is useful to introduce 
at this stage the concept of a sendee usage interface. A service usage inter- 
face is simply the interface that the service exposes to its clients (17) . This 
means that the service usage interface is not different from the imported 
service interfaces in Figure 2.2; it is, however, the only interface viewed by 
a client application. 
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Figure 2.2. Service interfaces and implementation. 

Figure 2.2 distinguishes between two broad aspects of services: ser- 
vice deployment, which we examined already, versus service realization. 
The service realization strategy involves choosing from an increasing di- 
versity of different options for services, which may be mixed in various 
combinations including in-house service design and implementation, pur- 
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chasing/leasing/paying for services, outsourcing service design and imple- 
mentation, and using wrappers and/or adapters to convert legacy system, 
COTS package, and ERP functionality into a service layer. 

Service descriptions are used to advertise the service capabilities, inter- 
face, behavior, and quality. Publication of such information about available 
services (in a service registry) provides the necessary means for discovery, 
selection, binding, and composition of services. In particular, the service 
interface description publishes the service signature while the service ca- 
pability description states the conceptual purpose and expected results of 
the service. The (expected) behavior of a service during its execution is 
described by its service behavior description (e.g., as a workflow process). 
Finally, the Quality of Service (QoS) description publishes important func- 
tional and non-functional service quality attributes, such as service meter- 
ing and cost, performance metrics (response time, for instance), security 
attributes, (transactional) integrity, reliability, scalability, and availability. 

Service implementation can also be very involved because in many occa- 
sions many organizations rely on single monolithic programs to represent 
a single service or service method implementation. But very often in order 
to fulfil the functions of a service multiple programs are involved, e.g., pro- 
grams that belong to multiple applications of new programs that belong to 
multiple applications. Application composition and integration very often 
is involved in fulfilling the service. At the logical level of the service we do 
not pay any attention to this. All we need to know is that there is a business 
function implemented in software somehow and this is the interface to it. 
At development time we care, however, how the service is implemented. 
More specifically, what are the methods and the internal construction of the 
implementation. 

The service in the basic SOA is designed in such a way that it can be in- 
voked by various service clients and is logically decoupled from any service 
caller ( loose coupling). Services can be reused and one does not have to 
look inside the service to understand what it does. There are no assumptions 
of any kind in the service as to what kind of service a consumer is using and 
for what purpose and in what context. In SOA the service is not coupled to 
its callers, in fact it knows nothing about them. However, the service callers 
are very much coupled to the service, as they know what the services are, 
what they call, and what they can accomplish. 
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Figure 2.3. The Extended Service Oriented Architecture. 



4. GRID SERVICES AND THE EXTENDED SOA 

The basic SOA does not address overarching concerns such as manage- 
ment, service orchestration, service transaction management and coordina- 
tion, security, and other concerns that apply to all components in a services 
architecture. Such concerns are addressed by the extended SOA (ESOA) 
(16) that is depicted in Figure 2.3. This layered architecture utilizes the 
basic SOA constructs as its bottom layer. 

The service composition layer in the ESOA encompasses necessary roles 
and functionality for the consolidation of multiple services into a single 
composite service. Resulting composite services may be used by service 
aggregators as components (i.e., basic services) in further service compo- 
sitions or may be utilized as applications/solutions by service clients. 

Service aggregators thus become service providers by publishing the ser- 
vice descriptions of the composite service they create. A service aggregator 
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is a service provider that consolidates services that are provided by other 
service providers into a distinct value added service. Service aggregators 
develop specifications and/or code that permit the composite service to per- 
form functions that include the following: 

■ Coordination: controls the execution of the component services, and 
manages dataflow among them and to the output of the component 
service (e.g., by specifying workflow processes and using a workflow 
engine for run-time control of service execution). 



■ Monitoring: allows subscribing to events or information produced by 
the component services, and publish higher-level composite events 
(e.g., by filtering, summarizing, and correlating events). 



■ Conformance: ensures the integrity of the composite service by 
matching its parameter types with those of its components, imposes 
constraints on the component services (e.g., to ensure enforcement 
of business rules), and performs data fusion activities. 



■ QoS composition: leverages, aggregates, and bundles the compo- 
nent’s QoS to derive the composite QoS, including the composite 
service’s overall cost, performance, security, authentication, privacy, 
(transactional) integrity, reliability, scalability, and availability. 



■ Policy enforcement: Web service capabilities and requirements can 
be expressed in terms of policies. For example, knowing that a service 
supports a Web services security standard such as WS-Security is not 
enough information to enable successful composition. The client 
needs to know if the service actually requires WS-Security, what 
kind of security tokens it is capable of processing, and which one it 
prefers. The client must also determine if the service requires signed 
messages; and if so, it must determine what token type must be used 
for the digital signatures. Finally, the client must determine when to 
encrypt the messages, which algorithm to use, and how to exchange 
a shared key with the service. Trying to orchestrate with a service 
without understanding these details may lead to erroneous results. 
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The recently proposed standard Business Process Execution Language for 
Web services (BPEL) (5) is an XML-based effort to address the definition 
of a new Web service in terms of composition of existing services. A 
BPEL process is defined “in the abstract” by referencing and inter-linking 
portTypes specified in the WSDL definitions of the Web services involved 
in a process. 

Managing critical Web service based applications requires in-depth ad- 
ministration capabilities and integration across a diverse, distributed en- 
vironment. For instance, any downtime of key e-business systems has a 
negative impact on businesses and cannot be tolerated. To counter such 
a situation, enterprises need to constantly monitor the health of their ap- 
plications. The performance should be in tune, at all times and under all 
load conditions. Web service based application management is an indis- 
pensable element of the ESOA that includes performance management and 
business/application specific management. This requires that a critical char- 
acteristic be realized: that services can be managed. Service management 
includes many interrelated functions. The most typical functions include: 

1 Deployment: The Web services support environment should allow 
the service to be redeployed (moved) around the network for perfor- 
mance, redundancy for availability, or other reasons. 

2 Metrics: The Web services support environment should expose key 
operational metrics of a Web service, at the operation level, including 
such metrics as response time and throughput. In addition it should 
allow Web services to be audited. 



3 Dynamic rerouting: The Web services support environment should 
support dynamic rerouting for fail-over or load balancing. 

4 Life cycle/State management: The Web services support environ- 
ment should expose the current state of a service and permit lifecycle 
management including the ability to start and stop a service. 



5 Configuration: The Web services support environment should sup- 
port the ability to make specific configuration changes to a deployed 
Web service. 
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6 Change management and notification: The Web services support en- 
vironment should support the description of versions of Web services 
and notification of a change or impending change to the service in- 
terface or implementation. 



7 Extensibility: The Web services support environment should be ex- 
tensible and must permit discovery of supported management func- 
tionality in a given instantiation. 



8 Maintenance: The Web services support environment should allow 
for the management and correlation of new versions of the service. 

Web services management can be defined as the functionality required for 
discovering the existence, availability, performance, health, patterns of us- 
age, extensibility, as well as the control and configuration, life-cycle support 
and maintenance of a Web service or business process within the context of 
the extended services architecture. This definition implies that Web services 
can be managed using Web services technologies. In particular, it suggests a 
management model that applies to both Web services and business processes 
in terms of management topics, (identification, configuration, state, metrics, 
and relationships) and the aspects (properties, operations and events) used 
to define them. In fact, these abstract concepts apply to understanding and 
describing the manageability information and behaviour of any resource, 
including business processes and Web services. 

To manage critical applications/solutions and specific markets, ESOA 
provides managed services in the service management layer depicted at the 
top of the ESOA pyramid. The ESOA managed services are divided in two 
complementary categories: 

■ Sendee operations management that can be used to manage the ser- 
vice platform, the deployment of services and applications, and, in 
particular, monitor the correctness and overall functionality of aggre- 
gated/orchestrated services. 



■ Open service marketplace management that supports typical sup- 
ply chain functions, by providing a comprehensive range of services 
supporting industry-trade, including services that provide business 
transaction negotiation and facilitation, financial settlement, service 
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certification and quality assurance, rating services, service metrics, 
and so on. 

The ESOA’s service operations management functionality is aimed at 
supporting critical applications that require enterprises to manage the ser- 
vice platform, the deployment of services and the applications. ESOA’s ser- 
vice operations management typically gathers information about the man- 
aged service platform, Web services and business processes and managed 
resource status and performance, and supporting specific management tasks 
(e.g., root cause failure analysis, Service-Level Agreement monitoring and 
reporting, service deployment, and life cycle management and capacity 
planning). Operations management functionality may provide detailed ap- 
plication performance statistics that support assessment of the application’s 
effectiveness, permit complete visibility into individual business processes 
and transactions, guarantee consistency of service compositions, and de- 
liver application status notifications when a particular activity is completed 
or when a decision condition is reached. We refer to the organization respon- 
sible for performing such operation management functions as the service 
operator. Depending on the application requirements a service operator 
may be a service client or aggregator. 

In the context of service operations management it is increasingly im- 
portant for management to define and support active capabilities versus 
traditional passive capabilities. For example, rather than merely raising 
an alert when a given Web service is unable to meet the performance re- 
quirements of a given service-level agreement, the management framework 
should be able to take corrective action. This action could take the form of 
rerouting requests to a backup service that is less heavily loaded, or provi- 
sioning a new application server with an instance of the software providing 
the service if no backup is currently running and available. 

Service operations management should also provide global visibility of 
running processes, comparable to that provided by Business Process Man- 
agement (BPM). BPM promises the ability to monitor both the state of any 
single process instance and all instances in the aggregate, using present 
real-time metrics that translate actual process activity into key performance 
indicators (KPIs). Management visibility is expressed in the form of real- 
time and historical reports, and in triggered actions. For example, deviations 
from KPI target values, such as the percent of requests fulfilled within the 
limits specified by a service level agreement, might trigger an alert and an 
escalation procedure. 

Considerations need also be made for modelling the scope in which a 
given service is being leveraged: individual, composite, part of a long- 
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running business process, and so on. Thus, in addition to the above con- 
cerns, which relate to individual business processes or services, in order 
to successfully compose Web services processes, one must fully under- 
stand the service’s WSDL contract along with any additional requirements, 
capabilities, and preferences (also referred to as policies). For example, 
knowing that a service supports a Web services security standard such as 
WS-Security is not enough information to enable successful composition. 
The client needs to know if the service actually requires WS-Security, what 
kind of security tokens it is capable of processing, and which one it prefers. 
The client must also determine if the service requires signed messages; and 
if so, it must determine what token type must be used for the digital sig- 
natures. Finally, the client must determine when to encrypt the messages, 
which algorithm to use, and how to exchange a shared key with the service. 
Trying to orchestrate with a service without understanding these details 
will lead to erroneous results. Such concerns are addressed by the service 
operations management. Service operations management is a critical func- 
tion that can be used to monitor the correctness and overall functionality 
of aggregated/orchestrated services, thus avoiding a severe risk of service 
errors. In this way one can avoid typical errors that may occur when indi- 
vidual service-level agreements (SLAs) are not properly matched. Proper 
management and monitoring provides a strong mitigation of risks due to 
mismatches of aggregated SLAs, since the operations management level 
allows checking the correctness, consistency and adequacy of the mappings 
between the input and output service operations and aggregate services in 
a service composition. 

Another aim of ESOA’s service management layer is to provide support 
for open service marketplaces. Currently, there exist several vertical indus- 
try marketplaces, such as those for the semiconductor, automotive, travel, 
and financial services industries. Open service marketplaces operate much 
in the same way as vertical marketplaces, but are open. Their puipose is 
to create opportunities for buyers and sellers to meet and conduct business 
electronically, or aggregate service supply/demand by offering added-value 
services and group buying power (much like a co-op). The scope of such a 
service marketplace would be limited only by the ability of enterprises to 
make their offerings visible to other enterprises and establish industry spe- 
cific protocols by which to conduct business. Open service marketplaces 
typically support supply chain management by providing to their members 
a unified view of products and services, standard business terminology, and 
detailed business process descriptions. In addition, service marketplaces 
must offer a comprehensive range of services supporting industry-trade, 
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including services that provide business transaction negotiation and facili- 
tation, financial settlement, service certification and quality assurance, rat- 
ing services, service metrics such as number of current service requesters, 
average turn-around time, and manage the negotiation and enforcement of 
SLAs. ESOA’s service management layer includes market-management 
functionality (as illustrated in Figure 2.3) that is aimed at supporting these 
marketplace functions. The marketplace is created and maintained by a 
market maker (a consortium of organizations) that brings the suppliers and 
vendors together. The market maker assumes the responsibility of mar- 
ketplace administration and performs maintenance tasks that ensure the 
administration is open for business and, in general, provides facilities for 
the design and delivery of an integrated service that meets specific business 
needs and conforms to industry standards. 

The ESOA service management functions can benefit from grid comput- 
ing as it targets manageability. Service grids constitute a key component 
of the distributed services management as the scope of services expands 
beyond the boundaries of a single enterprise to encompass a broad range 
of business partners, as is the case in open marketplaces. For this purpose 
grid services can be used to provide the functionality of the ESOA’s service 
management layer (6, 18). 



5. THE SERVICE GRID BUS 

Grid services are used in the ESOA’s service management layer to pro- 
vide an enabling infrastructure for systems and applications that require 
the integration and management of services with the context of dynamic 
virtual marketplaces. Grid services provide the possibility of achieving 
end-to-end quality of service and address critical application and system 
management concerns. To this end grid services provide the grid infras- 
tructure over which services interact, aggregate, and coordinate through a 
distinct architectural tier. This infrastructure is called the service grid bus. 
The service grid bus (SGB) provides a high-level abstraction architecture 
and management facilities to allow services (within an open service mar- 
ketplace) to function as an integral unit and collaborate with other services. 
The SGB architecture provides facilities for registration, discovery, selec- 
tion/routing, business rules, filtering, routing, aggregation, fail-over, and 
topological mapping of service instances. The business rules govern the 
SGB’s automatic processing for incoming service requests over aggregated 
service instances. 
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selection/routing, 
event monitoring, 
workflow/transactions 



Figure 2.4. The service grid bus. 

The service bus is a logical construct that cares very little where or on 
what platform a service provider runs. A user interface, designed to exactly 
match the business requirements may consume the services provided by the 
service bus, leaving the enterprise a free hand to choose the most efficient 
service provider. 

An SGB is designed to provide a single service connectivity and a man- 
agement tier that addresses the following concerns: 

■ Reach and robustness: The SGB supports locating services anywhere 
in an open service marketplace and insulating them from connection 
failures, errors, and barriers such as firewalls, proxies, and caches. It 
guarantees that each service always sees an error-free connection to 
any other service. The application as a whole should be robust under 
transient or long-term failure of one or more service components. 

■ Policy and security management: Services need to describe their ca- 
pabilities and requirements to their environment and potential users. 
A collection of capabilities and requirements is referred to as a pol- 
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icy (9). A policy may express such diverse characteristics as service 
transactional capabilities, security, response time, pricing, etc. For 
example, a policy of a service may specify that all interactions must be 
invoked under transaction protection, that incoming messages have to 
be encrypted, that outgoing messages will be signed, that responses 
may only be accepted within a specific time interval, etc. Finally, ser- 
vices must be restricted to authorized producers and consumers. The 
SGB enforces the security policy uniformly and universally across 
the entire marketplace. 

■ Development time and cost: The SGB provides the facilities that 
allow services to be easily aggregated into composite, higher-level 
services that match the factoring of an application. New services and 
clients will be added throughout the lifetime of the application. That 
process must be managed quickly, efficiently and cost effectively. 

■ Scalability and performance: The SGB must be able to perform well 
despite slow components and long, unpredictable network latencies. 

The SGB lets service components interact over any network connec- 
tion, handling all network errors, barriers, and transient or extended off-line 
conditions. It provides support for a business transaction model and sup- 
port mechanisms for advanced transactional behavior of complex service- 
oriented business processes that span organizations (15). The transaction 
model allows expressing unconventional atomicity criteria, e.g. payment 
atomicity, conversation atomicity, contract atomicity, and possessing the 
ability to express collaborative agreements and business conversation se- 
quences that rely on transactional support. This model relies on a phased 
approach to business transactions so that all exchange of information be- 
tween partners on the terms they could commit to, for example, to fix price 
and quantity, are kept outside the “pure” transaction protocol. This results 
in enhanced flexibility and reduced latency and expensive transaction com- 
pensations and rollbacks in business interactions. The SGB’s asynchronous 
communications makes the application robust under transient service node 
failures, and allows transparent rerouting in case of prolonged failure. 

The SGB provides standard, high-level services for security, manage- 
ment, service interaction, and aggregation, greatly accelerating application 
development and deployment. The SGB should also be consistent with 
emerging Web services workflow and transaction standards such as Web 
Services Transactions (2), Web Services Coordination (1) and the Business 
Transaction Protocol (BTP) (13). Finally, the SGB supports linear scala- 
bility and high performance by offering native support for asynchronous 




46 



interaction, and allowing service endpoints to be managed for load balanc- 
ing, workload distribution, and fail-over. The SGB itself must be scalable 
and capable of supporting peak loads. 

Figure 2.4 illustrates a service sharing and aggregation SGB model for 
open service marketplaces. The SGB model allows services and the re- 
sources they use to be more easily shared by different constituencies within 
an open service marketplace. With its service grid foundation an open 
service marketplace provides the notion of a business sendee grid that au- 
tomatically dispatches the best service available from a pool of dynamically 
assembled service providers in order to meet the user’s need. Selection of 
a service is not just based on availability, but can also be based on QoS 
characteristics, as specified in SLAs and business arrangements. Selection 
of a service is performed automatically based on service policy, and the 
features provided by the SGB enable service providers to conceal the im- 
plementation complexity required to handle multiple client requests over 
heterogenous environments. 

The SGB invokes a service aggregation module to maintain its policy and 
states while serving external service requests. This module also performs 
selection and dispatching to find a service instance to execute a service 
request. The service aggregation module is also decomposed into modular 
functional units so that it is customizable to meet the special needs of diverse 
platforms, operations logic and so on. 

One of the major benefits of introducing a distinct integration tier in the 
form of the SGB to implement the ESOA’s service management layer is the 
ability to couple in value-added services that provide packaged solutions 
for common development needs. The SGB provides an asynchronous inter- 
action model that lets users and applications initiate and monitor multiple 
tasks and data feeds simultaneously, and immediately alerts them when a 
transaction completes or a critical event occurs. In this regard, the SGB 
allows dynamic data feeds and transaction events to be delivered to the 
users or applications immediately when they occur. The SGB delivers to 
users applications that let them view multiple key performance indicators in 
real-time, collaborate with other users, and take action when critical events 
take place. 



6. SOFTWARE AGENTS AND THE EXTENDED SOA 

The shift towards the Service Oriented Computing paradigm not only in- 
volves a new way of conceptualizing complex distributed applications, but 
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also calls for more abstract software development and deployment technolo- 
gies. Agent-oriented software engineering delivers such an abstraction (7). 

To qualify as an agent, a system is often required to have properties 
such as autonomy, social ability, reactivity, and proactivity. Other attributes 
which are sometimes requested (21) are mobility, veracity, rationality, and 
so on. The key feature which makes it possible to implement systems with 
the above properties is that programming is done at a very abstract level, 
more precisely, using a terminology introduced by Newell, at the knowl- 
edge level (12). Thus, we talk of mental states, of beliefs instead of machine 
states, of plans and actions instead of programs, of communication, negotia- 
tion and social ability instead of interaction and I/O functionalities, of goals, 
desires, and so on. Mental notions provide, at least in part, the software 
with the extra flexibility needed in order to deal with the intrinsic com- 
plexity of the applications mentioned in the first paragraph. The explicit 
representation and manipulation of goals and plans facilitates, for instance, 
a run-time “adjustment” of the system behavior needed to cope with unfore- 
seen circumstances, or for more meaningful interactions with other human 
and software agents. 

In the agent-oriented vision, software is built not by providing low level 
imperative lines of code to be followed sequentially, but rather by defining 
high-level goals to be achieved. In order for an agent to achieve its goals 
it must have a number of capabilities, most notably, an agent must have 
reasoning, communicating, and acting abilities. 

We now focus on the three main agent capabilities in the context of Web 
services: reasoning, communicating, and acting. 

Reasoning. Given a set of goals, knowledge about the world’s behavior, 
and information on the current status of the world, the agent must be 
able to reason to achieve the goals that have been delegated to him. 
The world is an electronic marketplace or a business grid, which is 
well structured, standardized and follows precise semantically de- 
fined business rules. Knowing a business process in the form of a 
BPEL description, a security or transactional requirement or a busi- 
ness rule in the form of a WS-Policy specification allows the agent 
to model precisely the world’s behavior and therefore to plan and act 
accordingly. 



Communicating. Agents must be able to communicate with one another 
and with services in order to cooperate, reach agreements and nego- 
tiate business interactions. This must happen via standardized lan- 
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guages such as those offered by XML-based Web services descrip- 
tions. For instance, agents may want to discover services offered in 
the world they populate by standard communication with UDDI reg- 
istries, ot they may want to subscribe to events published via standard 
WS-Notification language (4). 



Acting. To achieve the goals delegated to them agents must act (proactively 
and autonomously) in the environment they populate. In the Web 
service scenario, acting implies invocation of Web service function- 
alities. This is possible by invoking Web service operations described 
in the standard WSDL language. In this manner, agents are able to 
accomplish the task assigned to them. 

In general, the more the world in which the agent lives is explicitly semanti- 
cally defined, the easier it is for the agent to reason, plan and, hence, achieve 
its goals. Web services provide structure to the world in which agents re- 
side, as, for instance, they force a common language for interaction (e.g., 
WSDL to define basic Web service operations) or even provide state-based 
descriptions of an application’s behavior (e.g., a BPEL abstract process 
specification). However, this is not enough since we are only dealing with 
standardized syntactic descriptions with no semantic meaning attached to 
them. WSDL and BPEL specifications include no semantic attachments. 
This is potentially dangerous when specifying services in the context of 
processes. Consider, for instance, two semantically identical services pro- 
viding, say, the same insurance functionality. These could end up with two 
completely different BPEL descriptions. 

Two options are possible to overcome such a semantic gap between the 
Web service world and the agent technology: adding semantics to the Web 
services or adding knowledge and abilities to the agents. The Semantic Web 
service initiative (11) goes in the first direction, proposing to semantically 
tag all Web service descriptions, while other proposals go in the second 
direction enabling agents to be designed for specific Web service tasks (10). 

The latter option holds more promise to the world of service oriented 
computing as it is in line with the characteristics and requirements of agent 
technology that we mentioned in the outset of this section. These are also in 
line with previous research activities (14) in the area of e-business were we 
identified various types of business agents based on business role they per- 
form: application agents, personal agents, general business activity agents, 
information brokering agents, negotiation and contracting agents, system- 
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level support agents, e.g., agents for interoperation, planning and scheduling 
agents, business transaction agents, and security agents. 

In the context of service oriented computing we foresee that software 
agents could make an important contribution in connection with the roles 
undertaken in an ESOA. Agent technology could be used to provide two 
types of coarse agents: agents as service providers and agents as service 
clients. These two types of agents could be combined when a coarse agent 
behaves as a service aggregator (or market maker) in order to provide an 
added value services to other agents. 

When considering agent technology in support of service aggregator 
agents we could expect that each coarse aggregator agent could comprise 
five distinct types of more fine-grained agents which provide the five paramount 
functions for service aggregators that we identified in Section 4. Specifi- 
cally, we could identify the following types of agents: 

■ Coordination agents control the execution of single services and in- 
teract with them to achieve high-level complex business goals that 
have been delegated to them. 



■ Monitoring agents sense the world by subscribing to events of indi- 
vidual services and react to them by publishing higher-level events 
or communicating with other agents. 



■ Conformance agents achieve complex goals which may be confor- 
mance goals. A business rule may be formalized as a goal for the 
agent which will be enforced as the agent is composing a set of ser- 
vices. 



■ QoS composition agents: the goal of an agent may contain quality of 
service QoS specifications that the agent will achieve in composing 
the services. For instance an agent may choose only services that 
guarantee a specific response time in order to guarantee a specific 
total response time for the composed service. 



Policy enforcement agents: as for conformance and quality of service, 
policy constraints may be embedded in agent goals, therefore, an 
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agent may enforce policies of aggregated services when composing 
them into an added value service. 

In a similar manner to aggregator agents, market maker agents are also 
coarse agents comprising different types of more specialized fine-grained 
agents providing the service management functions required for managing 
service operations, open service marketplace and the business service grid 
functions (see Section 5) required for the SGB. Here we could have agents 
such as deployment agents, service selection agents (based on QoS cri- 
teria such as price, performance, availability), rerouting agents, life-cycle 
management agents, configuration/versionning agents, change management 
agents and so on. 



7. CONCLUSIONS 

In this paper we introduced the concepts behind Service Oriented Com- 
puting and explained how the basic Service Oriented Architecture helps 
deliver service-based applications. We argued that in order to provide the 
advanced functionality needed to deliver sophisticated e-business applica- 
tions an Extended Service Oriented Architecture is necessary. This ar- 
chitecture includes a service composition tier to offer necessary roles and 
functionality for the consolidation of multiple services into a single com- 
posite service. It also provides a tier for service operations management 
that can be used to monitor the correctness and overall functionality of ag- 
gregated/orchesteated services and support for open service marketplaces. 
We explained how grid services can be used to implement the service man- 
agement tier of the Extended Service Oriented Architecture by means of 
the service grid bus. Finally, we have outlined how agent-oriented tech- 
nology can be an enabling technology for achieving the Service Oriented 
Computing paradigm. 
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Abstract: Over the last decade, research in agent-based systems (ABS) has spawned a 

multi-faceted field, addressing a broad range of challenges and generating a 
varied array of technical approaches. Web service technologies, in contrast, 
have arisen in a more incremental fashion, with more modest aims, although 
the vision statements associated with Web services sometimes overlap 
significantly with those of ABS. Work on Semantic Web services aims to 
provide richer specifications of services, so as to enable fuller, more flexible 
automation of service provision and use, support the construction of more 
powerful tools and methodologies, and promote the use of semantically well- 
founded reasoning about services. This chapter provides an overview of OWL- 
S, a Semantic Web services ontology, and discusses its connections with work 
on agent-based systems. We argue that OWL-S takes some significant, 
although limited, steps towards a foundation for the deployment of agent 
technologies on the Web. 



1. INTRODUCTION 

Over the last decade, research in agent-based systems (ABS) has spawned a 
multi-faceted field, addressing a broad range of challenges and generating a 
varied array of technical approaches. ABS research topics may be divided, 
roughly, into those having to do with individual agents, and those having to 
do with multiagent systems (MAS). The agenda of ABS has been ambitious 
and, in many respects, visionary. ABS researchers have sought to endow 
individual agents with characteristics such as autonomy, proactivity, and 
cooperativeness. In the area of MAS, the focal areas have included agent 
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communication languages, extended conversations between agents, shared 
knowledge, shared activities, interoperation frameworks, and various kinds 
of middle-agents. 2 

In pursuing this agenda, most ABS approaches have emphasized various 
forms of reasoning employing rich representations of knowledge — about 
agent capabilities, tasks, beliefs, commitments, communications, and so 
forth. In this sense, ABS have always relied on “semantically rich” 
representations and techniques. 

Web service (WS) technologies, in contrast, have arisen in a more 
incremental fashion, with more modest aims, although the vision statements 
associated with Web services sometimes overlap significantly with those of 
ABS. Web Services Description Language (WSDL) [11], in essence, allows 
for the specification of the syntax of the input and output messages of a basic 
service, as well as other details needed for the invocation of the service. 
WSDL does not, however, support the specification of workflows composed 
of basic services. In this area, the Business Process Execution Language for 
Web Services (BPEL4WS) [2] has the most prominent status. With respect 
to registering Web services for purposes of advertising and discovery. 
Universal Description, Discovery and Integration (UDDI) [42] has received 
the most attention to date. 

At the same time, recognition is growing of the need for richer semantic 
specifications of Web services, so as to enable fuller, more flexible 
automation of service provision and use, support the construction of more 
powerful tools and methodologies, and promote the use of semantically 
well-founded reasoning about services. Because a rich representation 
language permits a more comprehensive specification of so many different 
aspects of services, it can provide a better foundation for a broad range of 
activities across the service lifecycle. For example, richer semantics can 
support greater automation of service selection and invocation (thus 
reducing the burden on service developers), automated translation of 
message content between heterogeneous interoperating services, automated 
or semi-automated approaches to service composition, and more 
comprehensive approaches to service monitoring and recovery from failure. 
Further down the road, richer semantics can help to provide fuller 
automation of such activities as verification, simulation, configuration, 
supply chain management, contracting, and negotiation of services. 

To meet this need, researchers have been developing languages, 
architectures and related approaches; the resulting body of work goes under 

2 Excellent overviews and reference lists for ABS can be found at 

http : //agents . umbc . edu/ introduction and 

http: //www. aaai . org/AITopics /html /agents .html . 
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the heading of Semantic Web services (SWS) [29], In particular, the authors 
of this chapter, members of the OWL-S Coalition, are involved in the 
development of the Ontology Web Language for Services (OWL-S) [34], 
which seeks to provide the building blocks for encoding rich semantic 
service descriptions, in a way that builds naturally upon OWL [27], the 
Semantic Web [3] language undergoing standardization at the World Wide 
Web Consortium (W3C). 

We note that several of our references here, and in several other chapters 
in this book, refer to DAML-S, (DARPA Agent Markup Language for 
Services) the name by which earlier versions of OWL-S were known. As of 
version 1.0 (which has been released a short while prior to this writing), the 
name was changed to OWL-S, so as to reflect the change in the underlying 
formalism, from DAML+OIL to OWL. (DAML-fOIL — DARPA Agent 
Markup Language + Ontology Inference Language — was the predecessor 
of OWL.) 

1.1 Relating Agents and Services 

How can one begin to characterize the relationship between agents and 
Web services? 

The vision of ABS encompasses a broad scope of challenges and 
approaches to distributed task handling by relatively autonomous 
components. The approach taken by commercial Web services, in contrast, 
is necessarily more incremental, as it is tied to near-term products and goals. 
The ambitions of work on Semantic Web services lies somewhere in 
between. 

ABS technology arose largely independently of the World Wide Web. 
From a historical perspective, one may view the work on Web services and 
(to a greater degree) Semantic Web services as efforts to bring aspects of 
agent-based approaches onto the Web (although the work has generally not 
been done with this as an explicitly stated goal). Generally speaking, this 
has been accomplished in relatively modest ways to date. In this chapter we 
discuss some of the ways in which this has been accomplished. 

From an architectural perspective, one can identify three possible views 
of the relationship between agents and services: 

(1) Agents use services . In this view, there is no attempt to envision Web 
services as belonging to the realm of agents. Individual services can remain 
relatively simple — providers of discrete capabilities accessed via fixed 
message exchange patterns, exempt from exhibiting proactivity, autonomy, 
or other more sophisticated attributes of agents. Indeed, in this view, some of 
the hardest challenges associated with Web services, such as automated 
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general service composition, could ultimately be relegated to the realm of 
agents, and left out of the scope of Web service standards. In general, this 
view creates no requirements for service infrastructure to support services 
that take on the more sophisticated attributes of agenthood. 

(2) Services are agents , although currently of a limited kind. In this 
view, which is the most ambitious regarding the future of Web service 
technology, individual services will ultimately be free to display the 
autonomy, proactivity, persistence, etc. that define the notion of software 
agenthood, and collections of services will interact with the flexible 
collaboration that defines the essence of MAS. Currently, however, it may 
be seen that most work on services falls short of this vision. In particular, 
individual services are for the most part conceived as reactive, short-lived, 
and intended to engage only two parties in a provider/requester style of use. 
Although some work (both in WS and in SWS) is aiming to break out of 
these limitations, it is clear that there’s a long ways to go yet. 

(3) Agents are composed of, deployed as, and dynamically extended by 
services. This view, which holds that agents are built up from Web services 
as building blocks [8], can be viewed as a middle ground between (1) and 
(2). It allows for a notion of service that’s more limited than that of (2), but 
which exists within a more extensive conceptual framework than is required 
for (1). This perspective draws on work that combines behavior-based 
robotics and reactive planning (e.g., Behavior-Oriented Design [7]), and is 
particularly well-suited to scenarios in which services embody devices that 
may be viewed as sensors or effectors of the world. 

We note that there may well be other views of the agent/service 
relationship, and it isn’t entirely clear which of these three has the greatest 
applicability; we expect that future developments will make this clear. 

In this chapter we have two primary aims: to provide an overview of 
OWL-S, and to show some of its more significant connections with work on 
software agents and multiagent systems. Although there is clearly no cut- 
and-dried characterization of these connections, nevertheless it is useful to 
trace some of the central similarities, differences, and lines of evolution. We 
emphasize that this is not meant to be a comprehensive survey: ABS is an 
enormous field, and we can only hope to touch on a small selection of the 
relevant work. As a unifying theme, we argue that OWL-S takes some 
essential, although limited, steps towards a foundation for the deployment of 
agent technologies on the Web. 

In the next four sections, we briefly present OWL-S, beginning with an 
overview, and turning then to its profile, process, and grounding ontologies. 
Following that, we discuss its relationship to work on ABS, organized under 
the topics of discovery (including capabilities declarations, advertising, and 
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matchmaking), agent communication languages (including conversational 
protocols); and service composition. 



2. OVERVIEW OF OWL-S 

OWL-S is an OWL ontology that may be used to specify semantically 
rich characterizations of services on the Web. OWL-S is organized into four 
parts. The profde describes capabilities and discriminating features of Web 
services for purposes of advertising and matchmaking. The process model 
provides a description of the structure of activities involved in providing the 
service, from which service requesters can derive information about service 
invocation and interaction patterns. The grounding is a description of how 
abstract information exchanges described in the process model are mapped 
onto actual concrete messages that flow between the provider and the 
requester. Finally, the service itself provides a means of bundling together 
instances of the top-level profile, process, and grounding classes that are 
meant to be used together. (Because the service concept introduces no new 
details apart from the bundling of these other elements, we do not give it a 
separate section in the organization of this chapter.) 

OWL-S complements industry efforts such as SOAP, WSDL and 
BPEL4WS. It builds upon these efforts by adding rich typing and class 
information that can be used to describe and constrain the range of Web 
service capabilities more effectively than can be done with XML data types. 
Further, in the process model, it captures not only the control flow and data 
flow of Web services, but also their prerequisites and side effects 
(preconditions and effects) in the world. OWL-S’ basis in OWL enables the 
grouping of like services and like data types into taxonomic hierarchies, 
together with definitions of the relationships and constraints between classes 
and their instances. The well-defined semantics enables formal automated 
manipulation of these structures, with known outcomes, thus providing a 
foundation for automation of a variety of Web service operations, such as 
discovery, matchmaking, interoperation, composition, enactment, 
monitoring, and recovery. 



3. DESCRIBING CAPABILITIES WITH 
OWL-S 

The representation of capabilities is supported by the profde module of 
OWL-S, which provides a high-level view emphasizing the functionality of 
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the service; in other words, what the service does , rather than how it 
accomplishes its tasks. (The latter information, as discussed in Section 4, is 
provided by the OWL-S process model). Capabilities descriptions can have 
widely varying aspects. Capabilities may be described in terms of service 
categories, such as stock brokering, or functional transformations, such as 
the transformation from a ticker symbol to the related stock quote. 
Furthermore, a particular type of service may have many aspects. For 
instance, two services may act as stock brokers, but the way they perform 
their task may be very different in terms of delay on the market, precision of 
the report, cost and so on. The OWL-S profile provides a language to 
express the different aspects of service capabilities. Specifically, OWL-S 
profiles support three kinds of descriptions of capabilities: a hierarchical 
classification , a functional description , and a set of non-functional 
parameters that can be used to specify features of the service that are not 
captured by the other two descriptions. In the rest of this section we discuss 
these three descriptions in more detail. 

The hierarchical classification of a capability exploits the fact that any 
service profile is a concept expressed in OWL. It is therefore possible to 
construct ontologies of profiles that group together the common features of 
services performing similar functions. For example, as shown in Figure 1, it 
is possible to define the class FeeBasedService having properties needed to 
characterize the manner in which payment is made for the service (e.g. 
property paymentMethodAccepted). This class, in turn, could have 
PhysicalProductRetail as one of its subclasses, with properties that are 
characteristic of online retail sources, such as product and delivery Region. 
Consistent with the semantics of OWL (and with object-oriented practice in 
general), each subclass will declare properties that are appropriate to its level 
of specificity in the class hierarchy. The use of hierarchies of profiles allows 
service providers to specify precisely and economically what kinds of 
capabilities they provide, and allows service requesters to use the same 
framework to precisely specify what kinds of capabilities they seek. 

The functional view of the capabilities of a service describes the 
information transformation as well as state transformation performed by that 
service. At the information level, the service requires a set of inputs and 
produces a set of outputs; at the state description level, a service requires a 
set of preconditions to be satisfied and produces a set of effects. The 
functional description of the profile captures essentially the same 
information about inputs, outputs, preconditions, and effects (IOPEs), or a 
subset of the information, as the process model, as discussed in Section 4 
below. 

The last aspect of capability representations in OWL-S is provided by 
non-functional properties that are used to specify additional information 




OWL-S and Agent-Based Systems 



59 



<owl : Class rdf : ID= " FeeBasedService M > 

<rdf s : subClassOf rdf : resource=" kprof ile; #Prof ile H /> 

</owl :Class> 

<owl : Obj ect Property rdf : ID= "paymentMethodAccepted” > 

<rdf s : domain rdf : resource=" #FeeBasedService" /> 

<rdf s : range rdf : resource="&business; #PaymentMethod" /> 

</owl : Obj ect Proper ty> 

cowl : Class rdf : ID= " PhysicalProductRetail " > 

<rdf s : subClassOf rdf : resource= " #FeeBasedService" /> 

</owl : Class> 

cowl : Obj ectProperty rdf : ID= "product " > 

crdfs: domain rdf : resource^" # PhysicalProductRetail " /> 
crdf s : range rdf : resource= "&unspsc ; #Product " /> 
c/owl : ObjectProperty> 

cowl : Obj ectProperty rdf : ID= "deliveryRegion" > 

crdf s : domain rdf : resource^ " #PhysicalProductRetail " /> 
crdfs : range rdf : resource^ " kgeography ; #Region" /> 
c/owl : Obj ectProperty> 

cPhysicalProductRetail rdf : ID="Books4Sale"> 

cpaymentMethodAccepted rdf : resource= "&business ; #Mastercard" /> 
cpaymentMethodAccepted rdf : resource= "&business ; #Visa" /> 
cpaymentMethodAccepted rdf : resource="&business ; #MoneyOrder" /> 
cproduct rdf : resource="&unspsc ; iBooks" /> 

cdeliveryRegion rdf : resource="&geography; iNorthAmerica" /> 

</ Physical ProductRetail> 

Figure 1: Simple profile hierarchy and instance representing an online bookseller. 



about the Web service, such as security restrictions and quality of service 
information. The use of non-functional properties essentially recognizes that 
while two services may provide the same capability, in the sense that they 
compute the same function, the way they achieve this result may be very 
different and the resulting services may be qualitatively very different. For 
example, two services may provide tax advice, but one may be specialized 
on the US tax code, while the other may be specialized on the Italian tax 
code. The two services compute the same function, namely tax advice, but 
their contexts of applicability are different. 



4. DESCRIBING ACTIVITIES WITH OWL-S 

The OWL-S process model describes how the service works. For a one- 
step (atomic) service, it gives the complete information (about inputs and 
outputs) that is needed to interact with the service. For a multi-step 
(composite) service, it describes the control flow and data flow of the 
program that enacts the service. The process model has been designed for 
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<process : AtomicProcess rdf : ID= " LookupBook " > 

<process : haslnput> 

<process : Input rdf : ID= " InTitle " > 

<process :parameterType rdf : resource^ "dc :Title" /> 

</process : Input> 

</process : haslnput> 

<process : hasOutput> 

<process : UnconditionalOutput 
rdf : ID= "OutlSBN" > 

<process :parameterType rdf : resource^ " dc: Identifier " /> 
</process :UnconditionalOutput > 

<process : hasOutput> 

</process : AtomicProcess> 

<process : AtomicProcess rdf : ID= "BuyBook” > 

<process : haslnput> 

<process : Input rdf : ID= " InISBN" > 

<process :parameterType rdf : resource- "dc : Identifier" /> 
</process : Input> 

</process :haslnput> 

<process : hasOutput> 

<process :UnconditionalOutput 
rdf : ID= " OutReceipt " > 

<process :parameterType rdf : resource^ "business :E-receipt" /> 
</process :UnconditionalOutput> 

<process : hasOutput> 

</process : AtomicProcess> 



Figure 2: Partial functional description of two (simplified) atomic processes 

use by service requesters in connection with service selection, invocation, 
interoperation, composition, and monitoring, and by service tools for service 
simulation and verification. The OWL-S process model includes a number 
of elements that are typical of workflow languages, combining a process 
modeling language with both an Al-inspired action language and a language 
for describing classes and their inter-relationships. Further, the process 
model has a well-defined semantics. 

Central to an OWL-S process model, as with the profile, is the 
specification of a service's inputs, outputs, preconditions, and effects 
(IOPEs). Process inputs and outputs are named and typed using either 
OWL classes or data types provided by XML Schema. Preconditions , of 
which there may be any number, must all hold in order for the process to be 
invoked, and effects indicate what is accomplished by the service, or more 
generally, changes in the world brought about by the service. Conditions 
can be associated with outputs and effects, since the outputs and effects of a 
service are often predicated on some internal state of the system. 

Inputs, outputs, preconditions, and effects specified in a process model 
are complete, whereas in a profile they may be partial (that is, a selected 
subset that is most useful for purposes of advertising and discovery). 

OWL-S' process ontology is subdivided into three process types: atomic , 
simple , and composite processes. 
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<process: CompositeProcess rdf : ID= " FindAndBuyBook" > 

<process : Sequence> 

<process: components rdf :parseType= "Collection" > 
<process : Perform rdf : ID= " FindBookl " > 

<process : process rdf : resource="#LookupBook"> 
<process : hasBinding> 

<process : theParam rdf : resource="#InTitle"> 
<process : valueForm rdf :parsetype= "Literal "> 
cvalueOf > 

<theVar rdf : resource="#InTitle"> 

<fromProcess rdf : resource="#FindAndBuyBook"> 
</valueOf> 

</process : valueForm> 

</process :hasBinding> 

</process : Perf orm> 

<process : Perform rdf : ID="BuyBookl" /> 

<process : hasBinding> 

<process : Binding> 

<process : theParam rdf : resource^ " #InISBN"> 
<process : valueForm rdf :parsetype="#Literal"> 
<valueOf > 

<theVar rdf : resource= " #OutlSBN" > 
<fromProcess rdf :resource="#LookupBook"> 
</valueOf > 

</process : valueForm> 

</process : Binding> 

</process :hasBinding> 

</process : Perf orm> 

</process : components> 

</process : Sequence> 

</process :CompositeProcess> 

Figure 3: Elements of a composite process. 



Atomic processes are the units of invocation; that is, an atomic process, 
somewhat similarly to a programming language procedure, can be called by 
transmitting an invocation message (which carries its inputs) to the process, 
and its results returned in a response message. Thus, an atomic process 
executes in a single, non-interruptible step. The essence of an atomic process 
is in its IOPEs; thus, it provides the same kind of functional description as 
the service’s profile. 

Figure 2 shows two simple partial examples of atomic processes, each 
with a single input and a single output. LookupBook takes a book title as 
input. The type of the input named inTitle is dc : Title, and the type of 
the output named OutlSBN is dc : Identifier, both types from the 
Dublin Core ontology [17]. The returned value is an encoding of the 
International Standard Book Number (ISBN) for the book with the given 
title. Similarly, BuyBook takes an input of type dc : Identifier , and 
returns an output named OutReceipt, representing the purchase of the 
book. 
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In these examples, for lack of space, we omit a number of details, such as 
the payment and shipping information that would be needed to complete 
such a transaction, handling of unsuccessful outcomes (e.g., title unknown or 
out-of-stock), and preconditions and effects. A typical precondition for such 
a service might specify, “The buyer must have a current account”, and a 
typical effect might specify, “The buyer’s credit card is charged for the price 
of the book”. Outputs and effects may have conditions associated with 
them. For example, the output(s) and effect(s) for the condition “book-in- 
stock” could be distinguished from those for the condition “book-out-of- 
stock”. 

Simple processes are like atomic processes in that they are conceived of 
as having single-step executions. Unlike atomic processes, however, they 
are not directly invocable and are not associated with a grounding. Simple 
processes provide a means of abstraction; that is, they can provide abstract 
views of atomic or composite processes. 

Composite processes are constructed from subprocesses, which in turn 
can be either atomic, simple, or composite. Control constructs such as 
Sequence and If-Then-Else are used to specify the structure of a composite 
process. In addition to describing control flow, this structural specification 
also includes argument binding constructs for indicating the data flow. 

Figure 3 shows a fragment of a composite process, which expresses that 
the composite consists of sequentially invoking (“performing”) the atomic 
process LookupBook, and then invoking the atomic process BuyBook. The 
binding within the second Perform construct indicates that the output from 
LookupBook flows into the input of BuyBook. A composite process like 
this is enacted by the service client, with the execution of LookupBook and 
BuyBook handled by the service provider. 



5. DECLARING INVOCATION DETAILS 
WITH OWL-S 

The OWL-S grounding tells how the sendee is used ; that is, it specifies 
the details of how a computer program or agent can access a service. 
Typically, a grounding will specify some well known communication 
protocol, service-specific details such as port numbers used in contacting the 
service, and an unambiguous means of exchanging data elements of the 
types required and produced by the service [221. 

The default grounding approach provided by OWL-S relies on 
specification mechanisms already provided by WSDL, while at the same 
time exploiting the richer descriptions available through the use of the OWL 
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language [10]. In essence, it establishes a correspondence between each 
atomic process and a WSDL operation, and between each atomic process 
parameter and a WSDL message part. 

In summary, an OWL-S service is described by the three types of 
information presented above: one or more profiles tell what the service does 
(in support of advertising, discovery, matchmaking, and so forth), a single 
process model tells how the service works (in support of service invocation, 
interoperation, composition, and related activities), and one or more 
groundings tell how to access the service (in terms of message formats and 
other communications details). Whereas the grounding is concerned with 
the concrete details of message syntax and transport, the profiles and process 
model are more abstract specifications that can be used to support 
classification, planning, and other forms of reasoning about services, thus 
enabling fuller automation of service-related activities. 



6. OWL-S AND DISCOVERY 

Autonomous agents and Semantic Web services can be used to realize a 
distributed computation scheme in which problems are solved through 
interaction with other agents or Web services. Such a distributed scheme 
requires agents and Web services to discover partners that can contribute to 
the collaborative effort. The problem of discovering partners is essentially 
the same for agents and Semantic Web services 3 : given a goal, the discovery 
process should automatically locate those agents 4 that can achieve that goal. 

The process of discovery can be roughly divided into three stages: first, 
agents advertise their capabilities with a registry 5 such as UDDI. Second, an 
agent in need of a service requests, from the registry, references to providers 
of the capabilities needed by the agent. Third, the registry reports back to 
the requester one or more references to providers whose advertisements 
match the request. 

The success of the discovery process hinges on two requirements. First, 
a language is needed that allows service-providing agents to effectively 

3 The stress on Semantic Web services here is justified by the fact that, in the most 

conservative view, commercial Web services standards are meant to help programmers, 
rather than programs, to discover and “glue” multiple agents together. 

4 Since the discovery process is essentially the same for Web services and agents, in this 

section we do not make any distinction between agents and Web services, and we refer to 
both as agents. 

5 In our discussion we describe the most common discovery mechanism used by Web 

services. Depending on the overall system architecture other discovery mechanisms are 
possible. 
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describe their capabilities for the purpose of advertising them to the broader 
community. This same language should also allow service-seeking agents to 
formulate requests for the capabilities they need from service-providers. 
Second, an advertisement/request matching technology is needed that detects 
when the requested service is equivalent to the advertised service, even if the 
two descriptions are superficially very different. 

As described in Section 3 above, OWL-S directly addresses the first 
requirement of discovery by providing OWL concepts for the description of 
what agents do and the tasks that they accomplish. In the following section 
we show how OWL-S can be used to address the second requirement by 
defining algorithms that exploit the logical relations between the 
advertisements and the requests, abstracting away from superficial syntactic 
differences. We then explore the relationship between the view of discovery 
proposed by OWL-S and the views that have arisen from the fields of agent- 
based systems and Web services. 

6,1 Matching Capabilities 

The discovery process performs the matching of requests and 
advertisements to identify the agents that can perform a desired task. The 
problem of capability matching is that it is unrealistic to expect that the 
advertisement and the request describe exactly the same capability. Rather, 
the challenge of the matching process is to abstract away from the syntactic 
differences between the advertisements so as to extract the semantic 
similarities between the advertisement and the request, and verify whether 
the advertised capability is close enough to the capability requested. 

To address this challenge, OWL-S based matching algorithms exploit the 
semantics of the representation of the advertisements and requests; 
furthermore, they provide a flexible matching mechanism that recognizes the 
degree of matching between the advertisement and the request. Exploiting 
the semantics of descriptions and defining a flexible matching are closely 
related issues. Indeed, by analyzing the semantic relation between the 
advertisement and the request it is possible to derive a scoring function 
between the two concepts. 

A number of capability matching algorithms have been proposed for 
OWL-S, using different types of information provided by the service profile 
and the available ontologies to match between service requests and 
advertisements. Some matching algorithms, such as those described in [9] 
and [18], rely on the subsumption computation provided by OWL inference 
engines to infer the relation between the advertisement and the request. 
These matching algorithms rely on the ability to construct taxonomies of 
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service profiles that correspond to the different types of services that are 
present. Other matching algorithms, such as those in [5], [14], and [37], 
assume that matches are determined exclusively by the relations between 
inputs and outputs in the advertisement and in the request. Essentially, these 
matching algorithms perform two matches, one comparing outputs and one 
comparing inputs. If the output required by the requester is of a kind 
covered (subsumed) by the advertisement, then the inputs are checked. If the 
inputs specified in the request are subsumed by the input types acceptable to 
the service, then the service is a candidate to accomplish the requester’s 
requirement. 

Despite the different attempts to provide a matching algorithm for agent 
capabilities, many challenges are still open. First, the two methods of 
matching capabilities are not guaranteed to converge to the same set of 
agents. This is partly because the functional and taxonomical 
representations convey capability information in very different ways that 
may not lead to compatible representations for the same capability. The 
second problem is that no matching has been proposed that extends to 
preconditions and effects. Finally, there is no predefined set of non- 
functional parameters and by and large each type of parameter may require a 
specialized matching process as shown by attempts to match on security 
requirements [13]. 

6.2 Relationship with Agent Technology 

The OWL-S service profile is grounded in the research on agent 
discovery in open multiagent systems, and has been influenced by systems 
such as LARKS [40], OAA [21] and InfoSleuth [33]. 

In this area, a primary contribution of the multiagent literature has been 
defining the goal of discovery in multiagent systems as the problem of 
finding the agent(s) that can perform a given task. Ultimately, this problem 
requires a goal directed search where the agent is located on the basis of the 
tasks that it performs - i.e., its capabilities - rather than on the basis of 
incidental properties such as name, port type or keywords attached to the 
agent. As a consequence, research in multiagent systems provides schemas 
for representation of capabilities that are reflected in OWL-S. Specifically, 
LARKS and OAA provides different perspectives on the goal directed view 
of the capabilities of agents, while InfoSleuth provides a way to represent 
classifications of agent functionalities. 

The second contribution of research in multiagent systems has been to 
reveal the importance of the semantic matching of capabilities. Essentially, 
it is realized that capability descriptions and capability requests may 
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syntactically be very different. Hence, any attempt to match that does not 
include an abstraction to semantics is bound to fail. The key insight 
provided by the multiagent community has been to claim the need for 
ontologies during the matching process that would support a flexible 
matching between request and advertisement with a measure of the degree of 
match. 

6.3 Relationship with UDDI and WS Technology 

UDDI is a World Wide Web initiative, lead by the OASIS Consortium 6 , 
to develop a standard specification for industrial strength registries of Web 
services. UDDI allows businesses to register their presence on the Web by 
specifying their points of contact both in terms of the ports used by the 
service to process requests and in terms of the physical contacts with people 
who can answer questions about the service. In addition, UDDI provides a 
language to specify an unbounded set of features of services that can help 
the process of service location and selection as well as service invocation. 
UDDI enjoys the wide support of many prominent software and hardware 
companies that have invested heavily in Web services. Because of this 
support, UDDI is becoming the de facto standard repository of Web 
services. 

The main limitation of UDDI is that it does not provide a capability 
representation language such as the OWL-S service profile. As a 
consequence, UDDI does not provide capability based search. The result is 
that UDDI supports the location of information about the Web service, once 
it is known which Web service to use, but it is impossible to locate a Web 
service only on the basis of what problems it solves. 

OWL-S and UDDI complement each other. UDDI provides an Internet- 
wide distributed registry that is virtually an industry standard. On the other 
side, OWL-S provides the information required for capability matching. The 
OWL-S/UDDI matchmaker [38] integrates OWL-S capability matching into 
the UDDI registry. This integration is based on the mapping of OWL-S 
service profiles to UDDI representations shown in Figure 4. 



6 See http://www.oasis-open.org 
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Figure 4. The OWL-S to UDDI mapping 

The integrated OWL-S/UDDI registry provides all the functionalities 
provided by UDDI using exactly the same API, so that any UDDI can 
interact with it to retrieve information about available Web services. In 
addition, OWL-S/UDDI supports capability matching by taking advantage 
of OWL-S capability representation and the matching process proposed in 
[36]. The result is a UDDI in which it is possible to search for, and find, 
Web services by their capabilities. 



7 . OWL-S AND AGENT COMMUNICATION 
LANGUAGES 

OWL-S explicitly supports the description of services as classes of 
activities, so that agents can reason about the possible benefit of using them, 
determine the content of the messages necessary to invoke them, and 
interpret responses from them. This is substantially different than the 
rationale behind agent communication languages (ACLs), such as the 
Knowledge Query and Manipulation Language (KQML) or the Foundation 
for Intelligent Physcal Agents (FIPA) ACL, developed during the 1990’s. 

ACLs like KQML and FIPA were designed primarily to provide a 
uniform syntax and semantics for messages with arbitrary content, passed 
between software agent peers. They divided messages into several layers, 
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and provided a specific syntax and semantics only for the outer layer, which 
supplied information about the message, its handlers (sender and recipient), 
its context (as it might relate to a prior message or sequence) and the 
language and ontologies used for the inner content layer which could be in 
any format or language. The semantic content that was standardized in these 
languages consisted of a set of performative types , or message types, 
representing the conversational attitude of the sender toward the content. 
The term performative comes from Speech Act theory. ACL performatives 
include 'request’, ‘tell’, 'ask’, ‘accept’, ‘reject’, 'deny’, etc. 

Just as ACLs were explicitly a model for messages, providing a standard 
meta-model so that they could be arranged in conversations, WSDL is a way 
of representing messages in the Web services world. WSDL models services 
as bundles of message patterns, grouped into simple sequence arrangements, 
such as input-output pairs. In contrast, the OWL-S process ontology is a 
framework for describing more abstractly the service activities themselves, 
and likely sequences of such activities. OWL-S descriptions of the inputs 
and outputs of individual atomic activities characterize the information 
conveyed in the underlying WSDL input and output messages. The OWL-S 
grounding model translates the inputs and outputs of OWL-S service 
descriptions from OWL into the XML elements of corresponding WSDL 
messages. But it can just as properly be used to translate that information 
into a KQML or FIPA message format for communications with agents that 
provided services using an ACL message transport mechanism. UMBC’s 
implementation of the Trading Agent Game [46] provides an example of this 
way of using OWL-S. 

OWL-S groundings used with KQML or FIPA must relate atomic 
processes to ACL message patterns with specific performatives and perhaps 
even specific content forms. The performatives referenced in these 
messages patterns depend on the type of service provided, and the kind of 
action triggered by the message. For example, an informational service 
would have its inputs grounded into an ASK message, while its outputs (the 
reply) could be an INFORM or TELL (depending on the ACL dialect). A 
service that resulted in a purchase would have inputs grounded in a 
REQUEST message pattern, while its outputs might be (conditionally) an 
ACCEPT or REJECT message pattern. The content pattern of the message 
would in each case have to contain information about the specific service 
(such as its type), and serialized descriptions of the input or output 
parameters of the service. Each reply would also be accompanied by an IN- 
REPLY-TO property referencing the corresponding input message 
requesting the service action. 

Just as performatives are implicit in the activity model of OWL-S 
processes, the information about message sequencing that is present in ACLs 
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is represented in OWL-S by inputs and outputs of processes, and activity 
sequences, the latter modeled using the control constructs for forming OWL- 
S composite processes. ACLs use the message field IN-REPLY-TO to 
specify a conversational token that can be used to mark messages as 
responses to specific other messages, since messages can arrive 
asynchronously. OWL-S simply describes the semantics of sets of inputs and 
outputs of a process, which must be translated into messages. 

In summary, OWL-S abstracts away the details of the message-level 
interactions of both ACLs and web service message languages like WSDL. 
Instead, it focuses on characterizing the content and workflow of interactions 
with services so that client systems can perform the reasoning necessary to 
interoperate with them automatically. 



8. OWL-S AND TASK COMPOSITION 

Web service composition (WSC) is the process of selecting, combining 
and executing Web services to achieve a user’s objective. “Make the travel 
arrangements for my WWW2004 conference trip” or “Buy me an Apple 
iPod at the best available price” are examples of user objectives that might 
be addressed by such composition. Human beings perform manual WSC by 
exploiting their cultural knowledge of what a Web service does (e.g., that 
www.apple.com will debit your credit card and send you an iPod), as well as 
information provided on the service’s Web pages, in order to execute a 
collection of services to achieve some objective. To automate WSC, all this 
information must be encoded explicitly in an unambiguous computer 
interpretable form. None of the existing industrial standards for WS 
description encode this level of detail. Further, the descriptions they provide 
are not unambiguously computer interpretable and as a consequence not 
reliably manipulated by an automated reasoning system; hence the need for 
OWL-S. 



8,1 The Need for OWL-S 

Automated WSC is akin to both an AI planning problem and a software 
synthesis problem, and draws heavily on both of these areas of research [28]. 
In order to perform automated WSC, a reasoning system must order, 
combine and execute Web services that collectively achieve the user’s 
objective. This involves resolving constraints between Web service inputs, 
outputs, preconditions and effects (IOPEs) and (typically) the outputs and 
effects (OEs) the user desires. For example, if one starts with an agent’s goal 
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(some desired outputs and effects), and matches it to the outputs and effects 
of a Web service (modeled as a process), the result is an instantiation of the 
process, plus descriptions of new goals to be satisfied based on the inputs 
and preconditions of that process. The new goals (inputs and preconditions) 
then naturally match other processes (outputs and effects), so that 
composition arises naturally. The constraints between these inputs, outputs, 
preconditions and effects dictate the composition of Web services. Two 
types of composition problems can be distinguished: i) those that involve 
only information-providing services, and ii) those that involve both 
information-providing and world-altering services. The former requires a 
rich semantic representation of inputs and outputs (IO). The latter requires a 
like representation of IOPEs. Recall that the effects (E) are the side effects 
of the program (e.g., that www.apple.com will debit your credit card and 
send you an iPod). Web service preconditions and (conditional) effects are 
not encoded in any existing industrial standard. They are encoded, in 
unambiguous computer-interpretable form in OWL-S, as described in 
Section 4. Since they supplement the information contained in WSDL, 
there is no grounding for these features at the WSDL level. 

In addition to matching IOPEs, the automated WSC problem also can 
involve selecting from among alternative Web services that match the IOPE 
constraints of the composition problem. For example, there are many Web 
services from which a user can buy an iPod. In order to select from among 
alternative services, a composition engine also requires some form of service 
selection. This is akin to the discovery problem described in Section 6, and 
as argued there, requires the OWL-S representation of the properties, 
capabilities and functioning of a Web service as described in Section 3. 

8.2 ABS and Service Composition 

ABS technology and research on reasoning about action and change have 
had a significant influence on the evolution of techniques for WSC. The 
views of the relationship between agents and services posited in Section 1.1 
yield two different characterizations of the WSC task in the context of ABS. 

If we view services as agents, then the composition problem can be 
conceived as a restricted form of a MAS task composition problem or 
planning problem (e.g., [6]). Each individual service is conceived as an 
agent with a set of capabilities, and the composition problem requires these 
services to coordinate to achieve some objective. Unfortunately, current 
Web services are not capable of the level of coordination required for true 
MAS task composition or planning. Most Web services are passive and 
taskable, demonstrating little proactivity. Their capabilities are brittle, 
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limited to execution of a fixed, preconceived workflow, generally with only 
two-party interaction. As such, realization of WSC by appealing to the view 
of services as agents generally requires creation of a single agent to 
coordinate the execution of other Web service agents, which does not exploit 
the power of MAS planning or task composition. While viewing WSC as 
MAS planning or task composition provides an ambitious vision for the 
evolution of empowered next-generation Web services and the role they 
might play in task composition, the research in MAS can only be exploited 
in a limited fashion with today’s Web services. 

The alternative view of agents composed of, deployed as, or dynamically 
extended by services, yields a much more compelling and fruitful 
characterization of the composition problem. In such a view, we conceive 
Web services as rich sensors and end effectors to an agent. Information- 
gathering Web services provide sensory capabilities to an agent, collecting 
information about the world for the agent. World-altering Web services act 
as end effectors, realizing changes in the world on behalf of the agent. In 
such a view of the world, the composition task is conceived as an agent- 
based planning problem. In what follows, we describe how techniques from 
agent-based planning and reasoning about action and change have been 
exploited to date for WSC, and the role that OWL-S plays in providing 
descriptions of Web services that enable realization of this vision. 

8.3 Realizing Service Composition 

There are several different approaches to WSC. All characterize OWL-S 
processes as actions with inputs, outputs, preconditions and effects, and use 
planning technology to achieve WSC. For example, the work of [24] models 
processes in the same format as a STRIPS operator [15] and plans from a 
sequence of Web services to achieve the user’s goal. In principle the system 
can string together a series of actions to arrive at a novel plan for dealing 
with a Web service. However, the system as described is at a very early 
stage of development, and fails to address such basic problems as how to 
deal with unpredictable results of actions. [30] also investigates the use of 
plan synthesis for WSC, though their focus is on the specific problem of 
planning with existing composite Web services and the work reported is 
preliminary. 

In contrast to this approach to WS Composition, several other researchers 
have taken the approach of using some sort of plan script or task model that 
describes approximately how to achieve some objective. This high-level 
plan is expanded and refined using automated reasoning machinery. The 
first such system to be built used the Golog system (e.g., [28], [29]). It 
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models both world-altering and information-providing services as actions 
with IOPEs, uses Golog procedures (modeled as OWL-S composite 
processes) to represent generic procedures of approximately how-to perform 
tasks, and uses interleaving online deductive synthesis and execution to 
generate a sequence of Web services customized to user’s preferences and 
constraints. Information gathering actions are executed as necessary, while 
world-altering actions are projected or simulated in order to enable the 
system to deliberate before committing to the execution of world-altering 
services. 

In a similar spirit, several other researchers (e.g., [39], [45]) have used 
the paradigm of Hierarchical Task Network (HTN) planning (e.g., [31]) to 
perform automated WS composition. In this paradigm, a planner is supplied 
with a library of standard plans, each characterized by what it is supposed to 
accomplish (that is, effects given preconditions). [45] uses the SHOP2 
system (e.g., [31], [32]), which is a state-of-the-art HTN planner. To solve a 
composition problem, SHOP2 must be given a top-level sketch of the 
composed plan (encoded in OWL-S as a CompositeProcess). However, 
many of the steps in the plan are described in a high-level vocabulary 
(analogous to the OWL-S control constructs) that allows multiple alternative 
subplans to carry out those steps. The system searches through ways of 
combining those subplans in order to arrive at an overall plan. Central to the 
SHOP2 approach to planning with Web services is the exploitation of the 
sharp distinction between information-providing and world-altering services 
in the planning process, given that the information provided by services is 
often critical to finding a plan. When mapping from a set of OWL-S service 
descriptions to a SHOP2 domain, information-gathering services are 
detected and encoded so as to be executed at planning time, rather than at 
run time (as so-called “book-keeping” operators, or, in current work, as 
SHOP2 evaluated preconditions). [28], [29], [39] also execute information- 
gathering services at plan time to reduce the search space for plans and to 
reduce non-determinism. 

HTN planning has also been used in [39] to compose Web services in the 
travel domain and in the organization of a B2B supply chain. The basic idea 
explored in this work is that Web services expand their own capabilities 
through collaboration. Consistently with the work presented above, 
especially [24] and [45], during the planning process, outputs and 
preconditions are satisfied either directly using an action that the Web 
service can perform or by asking other Web services to do something that 
satisfies that output or precondition. The location of the most appropriate 
Web service makes an essential use of the OWL-S/UDDI Matchmaker 
[37], [38] that performs a semantic capability match between a capability 
description and the service profiles of the available Web services. 
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There are many systems that deal with the restricted problem of 
composing services without consideration of preconditions and effects 
(PEs). Included in these is the work of [20] that augments BPEL4WS, a 
popular business-process language [2], with a composition module. When 
the BPEL4WS process requires a certain input, described as an XML data 
type, their system searches for a WS that can translate from available 
formats to the desired format. For example, if the process declares a need 
for a complex type containing a date in US format, and a known service 
supplies a data type identical except that the date is in UK format, the system 
searches for a translation service that can perform the desired data 
transformation. If necessary, it breaks the transformation process into 
substeps and recursively searches for methods to accomplish the substeps. A 
similar approach is integrated with an end-user interactive composition 
system, STEER, described in [23]. These approaches represent prototype 
solutions to an important subtask of service composition, namely, data- 
transfer interoperation . For it to work, it is necessary for process 

descriptions to include rich, computer-interpretable descriptions of the inputs 
and outputs of a process — the IO half of IOPEs. 

8.4 The Road Ahead 

While this early work is promising, we are still some distance from the 
goal of automated Web services composition. We have argued that we need 
rich, representations of Web services in a language with a well-defined 
semantics, to enable automated WSC. Specifically, we require rich, 
declarative descriptions of Web service IOPEs to determine a composition, 
and we require rich representations of the properties, capabilities and 
functioning of services to enable WS selection during the composition 
process. We have achieved both these requirements in great measure with 
OWL-S. In contrast, current industrial standards for WS description only 
describe WS inputs and outputs and they do so in a language that is not 
richly expressive and is without a well-defined semantics. 

We also require rich declarative representations of composite processes 
(existing compositions of Web services, such as Amazon’s workflow) so 
that we can exploit them in our WS composition tasks. (Many of the 
existing WS composition technologies only compose atomic processes.) We 
have addressed the problem of describing composite processes in OWL-S, 
but we believe the solution can be improved upon by appealing to a 
language that is more expressive than OWL, leveraging emerging industrial 
process modeling standards. To realize the goal of automated WS 
composition, we also require further advances in automated 
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reasoning/planning technology for WS. A final barrier to the goal of 
automated WS composition is the need for wide-spread adoption of OWL-S 
WS descriptions. 

Despite the need for further work, the accomplishments of OWL-S and 
associated composition technologies provide immediate value-addition. 
With existing technology we can perform automated composition of 
information-gathering services. It has also been demonstrated [20] that we 
can augment existing industrial WS choreography and orchestration tools 
with composition technology for data-transfer interoperation and for run- 
time binding of Web services. These systems enable manual composition of 
WSs. We can augment this with some semantic integration of the data 
sources. Finally, as demonstrated, we can currently perform automated WS 
composition of both information-gathering and atomic world-altering 
services under controlled conditions. Automated WSC is at the heart of 
seamless interoperation among Web services. With adoption of approaches 
to WS description such as OWL-S and advances in agent-based planning- 
related technologies, we believe that broad-scale automated WSC is well 
within reach. 



REFERENCES 

[1] J. L. Ambite (ed.), Proceedings of the ICAPS2003 Workshop on Planning for Web 
Services , Trento, 2003. 

[2] T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. Leymann, K. Liu, D. 

Roller, D. Smith, S. Thatte (ed.), I. Trickovic, and S. Weerawarana, “Business Process 
Execution Language for Web Services”, Version 1.1, 2003. At 

http://w ww- 1 06. ibm.com/developerworks/ webservices/library/ ws-bpel/ . 

[3] T. Berners-Lee, J. Hendler, and O. Lassila, “The Semantic Web”. Scientific American, 
284(5):34— 43, 2001. 

[4] A. Bernstein and M. Klein, “High Precision Service Retrieval”. In Proceedings of the 
First International Semantic Web Conference (ISWC 2002), Sardegna, 2002. 

[5] B. Benatallah, M-S. Hacid, C. Rey and F. Toumani, “Request Rewriting- Based Web 
Service Discovery”. In Proceedings of the Second International Semantic Web 
Conference (ISWC 2003), pp 335-350, October 2003. 

[6] F. M. T. Brazier, B. Dunin-Keplicz, J. Treur, and R. Verbrugge, “Modelling Internal 
Dynamic Behaviour of BDI Agents”. In Proceedings of the ModelAge Workshop , 
1997, pp. 36-56. 

[7] J.J. Bryson and L. A. Stein, “Modularity and Design in Reactive Intelligence”. In 
Proceedings of the 17 th lnt’l. Joint Conference on Artificial Intelligence , pp. 1115-1120. 
Morgan Kaufmann, San Francisco, 2001. 

[8] J. J. Bryson, D. L. Martin, S. A. McIIraith, and L. A. Stein, “Toward Behavioral 
Intelligence in the Semantic Web”. In IEEE Computer , pp. 48-54, November 2002. 




OWL-S and Agent-Based Systems 



75 



[9] I. Constantinescu and B. Faltings, “Efficient Matchmaking and Discovery Services”. In 
Proceedings of the IEEEAVIC International Conference on Web Intelligence (WI03). 
Halifax, Canada. 2003 

[10] DAML Services Coalition (alphabetically A. Ankolekar, M. Burstein, J. Hobbs, O. 
Lassila, D. Martin, D. McDermott, S. Mcllraith, S. Narayanan, M. Paolucci, T. Payne, 
K. Sycara), “DAML-S: Web Service Description for the Semantic Web”. In 
Proceedings of the International Semantic Web Conference (ISWC), pages 348-363, 
June 2002. 

[11] E. Christensen, F. Curbera, G. Meredith, and S.Weerawarana, “Web Services 

Description Language (WSDL) 1.1”, 2001. At 

http://www.w3.org/TR/2001/NQTE-wsdl-200 103 15 

[12] M. Dean, D. Connolly, F. van Harmelen, J. Hendler, I. Horrocks, D. McGuinness, P.F. 
Patel-Schneider, L. A. Stein, “Web Ontology Language (OWL) W3C Reference 
version 1.0”, 18 August 2003. At http://www.w3.org/TR/2002/WD-owl-ref-20021 112 . 

[13] G. Denker, L. Kagal, T. Finin, M. Paolucci, N. Srinivasan and K. Sycara, “Security For 
DAML Web Services: Annotation and Matchmaking”. In Proceedings of the Second 
International Semantic Web Conference (ISWC 2003), pp. 335-350, October 2003. 

[14] T. Di Noia, E. Di Sciacio, F. M. Donini and M. Mongiello, “Semantic Matchmaking in 
a P-2-P Electronic Marketplace”. Symposium on Applied Computing , pp. 582-586, 
Melbourne FL, 2003. 

[15] R. Fikes and N. J. Nilsson, “STRIPS: A New Approach to the Application of Theorem 
Proving to Problem Solving”. Artificial Intelligence 2, pp. 189-208, 1971. 

[16] I. Horrocks, P. F. Patel-Schneider, H. Boley, and S. Tabet, “OWL Rules Language, 
Draft version”. Technical report, 29 October 2003. 

[17] S. Kokkelink and R. Schwanzl, “Expressing Qualified Dublin Core in RDF / XML”. 
At http://dublincore.org/documents/dcq-rdf-xml/index.shtm] . 

[18] L. Li and I. Horrocks, “A Software Framework for Matchmaking Based on Semantic 
Web Technology”. In Proc. of the Twelfth International World Wide Web Conference 
(WWW 2003), pages 331-339, ACM, 2003. 

[19] T. W. Malone, K. Crowston, B. P. Jintae Lee, C. Dellarocas, G. Wyner, J. Quimby, C. 
S. Osborn, A. Bernstein, G. Herman, M. Klein, and E. O'Donnell, “Tools for Inventing 
Organizations: Toward a Handbook of Organizational Processes”. Management 
Science , 45 (3): 425 -443, March, 1997. 

[20] D. J. Mandell and S. A. Mcllraith, “Adapting BPEL4WS for the Semantic Web: The 
Bottom-Up Approach to Web Service Interoperation”. In Proceedings of the Second 
International Semantic Web Conference (ISWC2003), pp. 227—241, 2003 

[21] D. Martin, A. Cheyer and D. Moran, “The Open Agent Architecture: A Framework for 
Building Distributed Software Systems”. In Applied Artificial Intelligence , 13(1-2), 
1999, pp 92-128. 

[22] D. Martin, M. Burstein, O. Lassila, M. Paolucci, T. Payne, S. Mcllraith, “Describing 

Web Services using OWL-S and WSDL”. May 2004. At 

http://www.daml.org/services/owl-s/ 1 . 1/owl-s-wsdl.html 

[23] R. Masuoka, Y. Labrou, B. Parsia, and E. Sirin, “Ontology-Enabled Pervasive 
Computing Applications”. In IEEE Intelligent Systems , 18(10):68-72, 2003. 

[24] D. McDermott, “Estimated-Regression Planning for Interaction with Web Services”. In 
Proceedings of the Sixth International Conference on AI Planning and Scheduling, pp. 
204—211,2002. 




76 



[25] D McDermott, “The Planning Domain Definition Language Manual”. Yale Computer 
Science Report 1165 (CVC Report 980003), 1998. 

[26] D. McDermott and D. Dou, “Representing Disjunction and Quantifiers in RDF”. In 
Proceedings of the First International Semantic Web Conference (ISWC2002), Seattle, 
2002 . 

[27] D. L. McGuinness and F. van Harmelen, “OWL Web Ontology Language Overview”. 
World Wide Web Consortium (W3C) Candidate Recommendation. August 18, 2003. 
At http://www.w3 .org/TR/owl- features/ . 

[28] S. Mcllraith and T. Son, “Adapting Golog for Composition of Semantic Web Services”. 
In Proc. Eighth International Conference on Knowledge Representation and Reasoning 
(KR2002), pp. 482-493, Toulouse, 2002. 

[29] S. Mcllraith, T.C. Son and H. Zeng, “Semantic Web Services”. In IEEE Intelligent 
Systems , Special Issue on the Semantic Web , 16(2):46— 53, March/ April, 2001. 

[30] S. Mcllraith and R. Fadel, “Planning with Complex Actions”. In Proceedings of the 
Ninth International Workshop on Non-Monotonic Reasoning (NMR2002), pages 356- 
364, Toulouse, April, 2002. 

[31] D. S. Nau, Y. Cao, A. Lotem, and H. Munoz-Avila, “SHOP: Simple Hierarchical 
Ordered Planner”. In Proceedings of the International Joint Conference on Artificial 
Intelligence ( IJCAI-99 ), pp.968 — 973, Stockholm, 1999. 

[32] D. Nau, T.-C. Au, O. Ilghami, U. Kuter, W. Murdock, D. Wu, and F. Yaman, “SHOP2: 
An HTN Planning System”. Journal Artificial Intelligence Research , 20, 2003. 

[33] M. H. Nodine, A. H. H. Ngu, A. R. Cassandra, and W. Bohrer, “Scalable Semantic 
Brokering over Dynamic Heterogeneous Data Sources in InfoSleuth™ . In IEEE 
Transactions on Knowledge and Data Engineering, 15(5), pp 1082-1098, 2003. 

[34] OWL-S Coalition, “OWL-S 1.1 Release”. At http://www.daml.Org/services/owl-s/l. 1/ . 

[35] M. Paolucci, A. Ankolekar, N. Srinivasan, and K. Sycara, “The DAML-S Virtual 
Machine”. In Proc. Second International Semantic Web Conference (ISWC 2003), 
Sanibel Island FL, 2003. 

[36] M. Paolucci, N. Srinivasan, K. Sycara, and T. Nishimura, “Toward a Semantic 
Choreography of Web services: from WSDL to DAML-S”. In Proc. Second 
International Semantic Web Conference (ICWS 03), Sanibel Island FL, 2003. 

[37] M. Paolucci, T. Kawamura, T. R. Payne, and K. Sycara, “Semantic Matching of Web 
Services Capabilities”. In Proc. First International Semantic Web Conference 
(ISWC2002), Seattle, 2002. 

[38] M. Paolucci, T. Kawamura, T. R. Payne, and K. Sycara, “Importing the Semantic Web 
in UDDI”. In Proc. E-Services and the Semantic Web (ESSW02), Toronto, 2002. 

[39] M. Paolucci, K. Sycara, and T. Kawamura, “Delivering Semantic Web Services”. In 
Proceedings of the Twelfth World Wide Web Conference (WWW2003), Budapest, 
Hungary, May 2003, pp 111- 118. 

[40] K. Sycara, M. Klusch, S. Widoff and J. Lu, “Dynamic Service Matchmaking Among 
Agents in Open Information Environments”. In ACM SIGMOD Record (Special Issue 
on Semantic Interoperability in Global Information Systems), 28(1), 1999, pp 47-53. 

[41] The Rule Markup Initiative. At http://www.dfki.uni-kl.de/ruleml/ . 

[42] The Universal Description, Discovery and Integration (UDDI) protocol. Version 3, 
2003. At http://www.uddi.onr/ 




OWL-S and Agent-Based Systems 



77 



[43] Web Services Choreography Working Group. At http://www.w3.org/2002/ws/chor/ 

[44] Web Services Description Working Group. At http://www.w3.org/2002/ws/desc/ 

[45] D. Wu, B. Parsia, E. Sirin, J. Hendler, and D. Nau, “Automating DAML-S Web 
Services Composition Using SHOP2”. In Proc. Second International Semantic Web 
Conference (ISWC2003), Sanibel Island FL, 2003. 

[46] Y. Zou, T. Finin, L. Ding, H. Chen, R. Pan, “Using Semantic Web technology in Multi- 
Agent Systems: a case study in the TAGA trading agent environment”, In Proc . Fifth 
International Conference on Electronic Commerce, pp 95-101, Pittsburgh PA, 2003. 




Chapter 4 

A BROKER FOR OWL-S WEB SERVICES 



Massimo Paolucci, Julien Soudry, Naveen Srinivasan and Katia Sycara 

The Robotics Institute , Canegie Mellon University 
paolucci,jsoudry,naveen, katia@cs.cmu.edu 



Abstract Brokers are widely used in distributed information systems such as Multi-agent 
systems and distributed databases. However, there has not been a detailed anal- 
ysis of Broker architecture and no general solution has been proposed on how 
the Brokers’ tasks have to be accomplished. In this paper, we provide a detailed 
analysis of these tasks in the setting of OWL-S Web Services, and an implemen- 
tation based on OWL-S. We show that while OWL-S is adequate to provide all the 
information that is needed by the Broker, the straightforward implementation of 
the Broker using OWL-S results in a paradoxical situation. We solve this paradox 
by extending the Process Modeling language of OWL-S. Finally, we propose a 
solution to a number of issues that arise in the brokered management of the inter- 
action between Web services such as the abstraction from queries to capabilities 
required to solve that query, and management of the knowledge required by the 
Broker to control the multi-party interaction. 



1. INTRODUCTION 

Brokering is a natural coordination and mediation mechanism that we often 
encounter in our daily life. A common example of Brokers are stock Brokers 
that mediate between the stock market and its investors. Brokers play a role 
when there is a need to facilitate the interaction between two or more parties. 
For example, if two parties want to communicate, but they do not share a 
common language, Brokers may provide translation services, or if the two 
parties do not trust each other, a Broker may provide a trusted intermediary 
(e.g. an escrow service for commercial transactions). Furthermore, Brokers 
may provide anonymization for one (or both) of the parties, by mediating the 
transaction. 

Not surprisingly, Brokers are one of the main discovery and synchronization 
mechanisms among autonomous agents (9, 22). Examples include the Open 
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Agent Architecture Facilitator (14) which mediates between OAA agents that 
collaborate toward the solution of a problem. Furthermore, Brokers have been 
widely used in many agents applications such as integration of heterogeneous 
information sources and databases (13), e-commerce (1 1), pervasive computing 
(4) and more recently in coordinating between Web services in the IRS -II 
framework (16). Finally, theoretical studies (9, 22) analyze trade-offs that 
result from the use of Brokers. On one side architectures based on Brokers are 
centralized and bound to have bottlenecks and single points of failure. On the 
other side. Brokers, can perform a range of coordination activities such as load 
balancing between different agents, and anonymization where the Broker acts 
as a proxy of an agent effectively hiding the provider or the requester of a given 
functionality. 

Because of their mediation and coordination properties as well as their wide 
applicability, Brokers are a natural candidate component for the Web services 
infrastructure. TheSOAP(lS) specification and WS Architecture group (WSA) 
(3) specifications have provisions for intermediaries, but their role is limited to 
message routing. Furthermore, WSA assumes the existence of policy enforcing 
guards and auditing guards that act as Brokers that verify that the transactions 
performed by the agents are consistent with current policies. However, Brokers 
with rich functionality of discovery and mediation, are not part of the Web 
services infrastructure. 

In the current Web services infrastructure, the only component that is devoted 
to discovery is UDDI (21). However, UDDI is a registry that does not perform 
any mediation between the requester and the discovered service provider. A 
number of services that satisfy a particular request could be found using UDDI, 
but then it is up to the requester to decide which web service to use and how 
to interact with the selected provider. The DAML-S/OWL-S Matchmaker (19) 
provides automated semantic matching of service requests to capability adver- 
tisements, but, after the matchmaker returns a list of candidate providers, the 
selection of the most suitable service is performed by the requester, which can 
use the DAML-S Virtual Machine (18) to invoke the selected service. 

In this paper, we provide an analysis of the requirements of a Broker that 
performs both discovery and mediation between agents and Web services. We 
show that such a Broker performs very complex reasoning tasks that include 
(1) the interpretation of the capability advertisements of service providers; (2) 
the interpretation of the requesters’ queries that must be fulfilled by a service 
provider; (3) finding the best provider based on the requester’s query; (4) in- 
vocation of the selected provider on behalf of the requester, interacting with 
the provider as necessary to fulfill the query, and (5) returning the query re- 
sults to the requester. The accomplishment of these tasks requires ontologies 
to describe capabilities of Web services, their interaction patterns and the do- 
main they operate on, and a logic that allows reasoning on those ontologies. 
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Furthermore, we will provide a description of an implementation of a Broker 
using OWL-S (7), a Web services description language based on OWL (8) and 
the Semantic Web (2). 

The implementation of the Broker also highlights some of the challenges 
of the automatic interaction between Web services. The first overall challenge 
concerns the selection of a suitable service provider to fulfill the requester’s 
query. The requester’s query is a particular instantiation of an input to an invo- 
cation of a service (e.g. “What is the five day forecast in Pittsburgh?”), while 
advertisements of Web services express the capabilities of the Web service; in 
other words the class of queries that it can answer (e.g. “I provide a service that 
gives weather information”). Therefore, the Broker cannot match directly the 
query against its advertisement store; rather, the Broker needs first to transform 
the query into the capabilities requested to answer it, and only then the match- 
ing can be effected. How this transformation can be automatically generated 
is a big challenge. 

The second major challenge for the Broker is the management of the interac- 
tion between the provider and the requester. Ideally, the Broker may try to act 
as the provider and present to the requester the same interaction protocol of the 
provider. Therefore the Broker may forward to the requester the information 
coming from the provider, and conversly forward to the provider the informa- 
tion that it receives from the requester. The problem is that in a Brokered system 
neither the requester that addresses a Broker nor the Broker itself know a priori 
which is a suitable provider. Hence they do not know what information the 
Broker needs to proceed with the transaction, nor what information the Broker 
will report to the requiester. It is impossible to specify how a requester can 
formulate its query to the Broker nor how the Broker can mediate interactions 
between a requester and a provider whose interaction protocol is known only 
at a later stage. 

In this paper, we present an approach to the development and implementa- 
tion of a Semantic Broker, namely a Broker that performs semantic discovery 
and mediation among Web service requesters and providers. The Broker uses 
OWL-S to perform its functions. Our approach provides solutions to the three 
challenges presented above. The solution necessitates an extension to OWL-S 
to address the problem of the initial lack of knowledge of the provider’s Process 
Model on the part of the requester and of the Broker. 

The rest of the paper is organized as follows. In Section 2, we present 
an overview of OWL-S. In Section 3, we provide a detailed analysis of the 
Broker, exploring its interaction protocol and the reasoning tasks that it has to 
accomplish. In Section 4, we show how OWL-S provides the information that 
the Broker needs to perform its tasks. In Section 5, we explore the problems 
that emerge from describing the Broker with OWL-S, and we describe the 
exec extension of OWL-S. In Section 6, we describe the basic features of our 
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implementation and provide details on how we address the reasoning problems 
of the Broker. Finally, in Section 7, we conclude. 



2. OWL-S 

OWL-S is a Semantic Web services description language that enriches Web 
services descriptions with semantic information from OWL (8) ontologies and 
the Semantic Web (2). OWL-S is organized in three modules: a Profile that 
describes capabilities of Web services as well as additional features that help to 
describe the service; a Process Model that provides a description of the activity 
of the Web service provider from which the Web service requester can derive 
information about the service invocation; a Grounding that describes of how 
abstract information exchanges described in the Process Model is mapped onto 
actual messages that the provider and the requester exchange. 

The role of the OWL-S Profile is to support the requester in (a) discovering 
suitable providers, and (b) selecting among them. The OWL-S Profile achieves 
the first goal, i.e. provider discovery, by prescribing ways for representing Web 
service capabilities. The Service Profile fulfills the second goal, i.e. service 
selection, by providing for the representation of additional information about 
the service, such as information describing provenance and quality or cost 
specifications of the Web service. 

A Web service capability is the description of the service functionality, i.e. 
what the service does. For example, the capability of a bookseller, such as 
Barnes and Noble, is to sell books. The capability of a Web service can be 
viewed in two ways: first as a service category within an ontology of services 
(e.g. selling books is-a selling products) or as a transformation of a set of 
inputs to a set of outputs (e.g. selling books transforms the inputs “book title” 
and “book author” to the output “book invoice”). OWL-S Profile describes 
capabilities of Web services by the transformation that they produce. Besides 
transforming inputs into outputs at an information level, invoking a Web service 
can produce effects in the real world and need preconditions to be satisfied. 
For example, invoking the book selling service and buying a book produces 
the effect in the real world that the requester’s credit card gets charged; a 
precondition for the invocation of the book selling service is that the requester 
has a valid credit card. 

In addition to capabilities, an OWL-S Profile provides provenance informa- 
tion that describes the entity (person or company) that deployed the service; 
and non-functional parameters that describe features of the services such as 
quality rating for the service. These pieces of information help a requester 
discriminate among different services with similar capabilities. For example, a 
requester may prefer a bookseller that has a Dunn and Bradstreet quality rating. 
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In order to make its capabilities known to service requesters, a service 
provider advertises its capabilities with infrastructure registries, or more pre- 
cisely middle agents (22), that record which agents are present in the system. 
A UDDI registry is an example of a middle agent, with the limitation that 
it can make limited use of the information provided by the OWL-S Profile. 
The OWL-S/UDDI Matchmaker (19, 20) is another example, which combines 
UDDI and OWL-S. Finally, the Broker defined in this paper is another example 
of a middle agent that performs both discovery and mediation. 

The second module of OWL-S is the Process Model. The Process Model 
has two aims: the first one is to show how the provider achieves its goals, 
and the second to provide the requester-provider interaction protocol. The 
first goal is achieved by allowing the provider to make public a description 
of its computation, to the extent that the provider feels comfortable to do so. 
The requester-provider interaction protocol is derived by the processes that 
the provider performs by locating when the provider needs information, and 
what type of information, and where it sends information, and what type of 
information. 

A Process Model defines a set of concurrent threads of execution. Each 
thread is an ordered collection of processes. OWL-S distinguishes between 
two types of processes: composite processes and atomic processes. Atomic 
processes correspond to operations that the provider can perform directly. Com- 
posite processes are used to describe collections of processes (either atomic, or 
composite) organized on the basis of some control flow structure. For example, 
a sequence of processes is defined as a composite process whose processes are 
executed one after the other. Other control constructs supported by OWL-S are 
conditional expressions, non-deterministic choices between alternative con- 
trol flows, and spawning of new concurrent threads. Finally, OWL-S includes 
looping constructs like while and repeat-until. 

The last module of OWL-S is the Grounding that describes how atomic pro- 
cesses which provide abstract descriptions of the information exchanges with 
the requesters, are transformed into concrete messages or remote procedure 
calls over the net. Specifically, the OWL-S Grounding is defined as a one to 
one mapping from atomic processes to WSDL (5) input and output message 
specifications. From WSDL it inherits the definition of abstract message and 
binding, while the information that is used to compose the messages is extracted 
through the execution of the process model during service invocation. 

Therefore, the Web services philosophy of interaction between a service 
requester and a service provider is that a requester would need to know the 
information that a service provider requires at different stages of the interac- 
tion. For example, in industrial standards, the requester-provider interaction 
is governed by knowledge of the provider’s Web services Description (WSD) 
given in WSDL, and in Semantic Web services, the requester-provider interac- 
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tion presupposes knowledge on the part of the requester of the Process Model 
(plus WSD) of the provider. 



3. OVERVIEW OF THE BROKER 

Brokers have been widely applied in many different applications and do- 
mains, therefore, not surprisingly, there are many different definitions of what 
a Broker is. We adopt the definition of the Broker protocol based on (9), and 
graphically summarized in Figure 4.1. Any transaction involving a Broker 
requires three parties. The first party is a requester that initiates the transac- 
tion by requesting information or a service to the Broker. The second party 
is a provider which is selected among a pool of provider as the best suited to 
resolve the problem of the requester. The last party is the Broker itself. 

The protocol in Figure 4.1 can be divided in two parts: the advertisement 
protocol, and the mediation protocol. In the advertisement protocol, the Broker 
first collects the advertisements of Web services that are available to provide 
their services. These advertisements, shown in Figure 4. 1 by straight thin lines, 
are used by the Broker to select the best provider during the interaction with 
the requester. The mediation protocol, shown in Figure 4. 1 using thick curve 
lines, requires (1) the requester to query the Broker and wait for a reply while 
the Broker uses its discovery capabilities to locate a provider that can answer 
the query. Once the provider is discovered, (2) the Broker reformulates the 
query for that provider, and finally queries it. Upon receiving the query, (3) the 
provider computes and send the reply to the Broker and finally (4) the Broker 
replies to the requester. 

In general, the execution of the protocol may be repeated multiple times. 
For example, the requester may have asked the Broker to book a flight from 
Pittsburgh to New York. Since there are multiple flights between the two cities, 
the provider may ask the Broker, and in turn the requester, to select the preferred 
flight. These interactions are resolved with multiple loops through the protocol. 
For example, the Broker translates the list of flights retrieved by the provider 
for the requester, through steps (3) and (4) of the protocol, and then translates 
the message with the selected flight from the requester to the provider, via steps 
(1) and (2) of the protocol. The only exception is that step (1) does not require 
any discovery since the provider is already known. 

In some cases, the Broker may be able to answer the request of information 
from the provider directly; therefore, it does not have to involve the requester 
in the interaction. For example, the requester’s query may request a seat on 
the cheapest flight from Pittsburgh to New York. When the provider reports all 
flights between the two cities, the Broker selects the cheapest one and responds 
directly to the provider without asking anything to the requester. Following 
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Providers 




Figure 4.1. The Broker's Protocol 

the protocol in Figure 4.1, these interactions are the result of the inner loop 
produced by the steps (3) and (2). The provider sends message (3) and the 
Broker responds directly with (2) without contacting the requester. 

The protocol described above shows that the Broker needs to perform a 
number of complex reasoning tasks for both the discovery and mediation part 
of its interaction. The discovery task requires the Broker to use the query to 
describe the capabilities of the desired providers that can answer that query, and 
then match those capabilities with the capabilities advertised by the providers. 
During the mediation process, the Broker needs to interpret the messages that 
it receives from the requester and the provider to decide how to translate them, 
and whether it has enough information to answer directly the provider without 
further interaction with the requester. In the next two sections, we will analyze 
these reasoning tasks in more detail. 

3.1 Discovery of Providers 

The task of discovery is to select the provider that is best suited to reply to 
the query of the requester. Following the protocol, providers advertise their 
capabilities using a formal specification of the set of capabilities they possess, 
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i.e. the set of functions that they compute. These capability specifications 
implicitly specify the type of queries that the provider can answer. 

The discovery process requires two different reasoning tasks. The first one is 
to abstract from the query of the requester to the capabilities that are required to 
answer that query. The second process is to compare the capabilities required to 
answer the query with the capabilities of the providers to find the best provider 
for the particular problem. 

The first problem, the abstraction from the query to capabilities, is a partic- 
ularly difficult one. Capabilities specify what a Web service or an agent does, 
or, in the case of information-providing Web services, what set of queries it 
can answer. For example, the capability of a Web service may be to provide 
weather forecasting, or sell books, or register the car with the local depart- 
ment of transportation. Queries instead are requests for a very specific piece 
of information. For example, a query to a weather forecasting agent may be to 
provide the weather in Pittsburgh, while a query to a book-selling agent may be 
to buy a particular book. Because of their difference, queries and capabilities 
are also expressed in very different formats. The task of the Broker therefore is 
to abstract from the particular query, to its semantics, i.e. what is really asked. 
Finally, the Broker must identify and describe in a formal way the capabilities 
that are needed to answer that query. 

The second task of the discovery process is to match the capabilities required 
to answer the query with the advertisements of all the known providers. Since 
it is unlikely that the Broker will find a provider whose advertisement is ex- 
actly equivalent to the request, the matching process can be very complicated, 
because the Broker has to decide to what extent the provider can solve the 
problems of the requester. 

3.2 Management of Mediation 

The second reasoning task that the Broker has to accomplish is to transform 
the query of the requester into the query to send to the provider. This process of 
mediation has two aspects. The first one is the efficient use of the information 
provided by the requester to the Broker; the second one is the mapping from 
the messages of the requester to messages to the provider and vice versa. 

Since the requester does not a priori know which is the relevant provider, 
the (initial) query it sends to the Broker and the query input that the (selected) 
provider may need in order to provide the service may not correspond exactly. 
The requester may have appended to the query information that is of no rel- 
evance to the provider, while the provider may expect information that the 
requester never provided to the Broker. In the example above, we considered 
the example of a requester that asks to book the cheapest flight from Pittsburgh 
to New York. However, besides the trip origin and destination, the selected 




A Broker For OWL-S Web Services 



87 



provider may expect date and time of departure. In the example, the requester 
never provided the departure time, and the provider has no use for the '‘cheap- 
est” qualifier. It is the task of the Broker to reconcile the difference between the 
information that the requester provided and the information that the provider 
expects, by ( 1) recognizing that the departure time was not provided, and there- 
fore it should be asked for, and (2) finding a way to select the cheapest flight 
among the ones that the provider can find. 

The other type of inference on the message-passing that the Broker has to 
perform is the mapping between ontologies and terms used by the two parties. 
For example, the requester may have asked for information on IBM whereas 
the provider expects inputs in terms of International Business Machine Cor- 
poration. A more complicated mismatch may be at the level of concepts and 
their relations in the ontologies used for inputs and outputs of the provider vis 
a vis the ontological information used by the requester. For example, the re- 
quester may have asked for the weather in Pittsburgh, but instead the provider 
can report only the weather at major airports. The task of the Broker in this 
case is to infer which is the most appropriate airport, and use it in the query 
to the provider. Therefore, instead of asking for the weather in Pittsburgh, the 
Broker asks the provider for the weather at PIT, where PIT is the code of the 
Pittsburgh International Airport. 

Finally, the Broker has the non-trivial task of translating between the differ- 
ent syntactic forms of the queries and replies. The examples that we discussed 
above assume semantic mismatches between the different messages that the 
Broker has to interpret and send. These messages must be compiled in an 
appropriate syntactic form, and despite their semantic similarity, the messages 
could be realized in very different ways. The task of the Broker is to resolve 
syntactic differences, and to formulate messages that all the parties can under- 
stand. 

In conclusion, the Broker performs a number of complex reasoning tasks 
that range from discovery to the interpretation, translation and compilation of 
messages. To accomplish these tasks, the Broker needs the support of a formal 
framework that allows complex reasoning about agents, what they do and how 
to interact with them. Furthermore, the Broker needs a way to translate the 
semantics of the information that it wants to communicate, into the syntactic 
form that the provider or the requester expects. 



4. OWL-S SUPPORT OF BROKER’S REASONING 

The OWL-S language and ontology provides constructs to support the Broker 
in both discovery and mediation between Web services. The OWL-S Profile 
supports the discovery process by providing a representation of capabilities of 
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Web services and agents. The OWL-S Process Model and service Grounding 
provide support for the interaction between the Broker and the requester and 
provider of the service. 

The discovery process requires a representation of capabilities of provider 
services and a representation of the capabilities that are required to answer the 
query. These capabilities are represented in OWL-S by the service Profile. In 
addition to the representation of capabilities, the analysis above showed that the 
Broker needs an abstraction process from the query to the capabilities needed 
to answer it, and a matching mechanism from the capabilities required for the 
query to the capabilities of the providers to select the best service provider to 
answer the query. 

A number of capability matching algorithms for OWL-S based Web services 
have been proposed (see (1, 17, 12, 19)) which exploit OWL ontologies and the 
related logics to infer which advertisements satisfy a request for capabilities. 
These algorithms can be used to solve the second problem: the matching from 
the capabilities required for the query to the capabilities of the providers. 

The first problem, the abstraction from the query to the capabilities, is more 
complicated. First of all, there is no explicit support in OWL-S for queries; 
nevertheless, it is easy to use the OWL Query Language (OWL QL) (6, 10) 
which relies on the same logics required by OWL-S. The transformation is 
still an open problem, which, to our knowledge, has not been addressed in the 
literature. In the next section, we propose an abstraction algorithm to transform 
queries into capabilities. 

After selecting a provider, the Broker has access to the provider’s Process 
Model from which it can derive the provider’s interaction protocol by extracting 
what information the provider will need, in what order, and what information it 
will return. For the rest of the interaction the Broker acts as the provider’s direct 
requester. However, this relation is not straightforward. Since the Broker acts 
on behalf of the requester, it must somehow transform the requester’s initial 
query (and all subsequent messages) into a query (or a sequence of queries) 
to the provider. This transformation is necessary since the requester does not 
have direct access to the Process Model of the provider, but interacts with the 
provider only through the Broker. We show how this transformation can be 
performed in Section 6.1. 

Furthermore, since the requester initiated its query without having access to 
the provider’s Process Model (since the provider was not known at the time 
of the requester’s query initiation), the Broker needs to infer what additional 
information it needs from the requester. Once it has done that, it then uses 
this knowledge to construct a new Process Model. This new Process Model 
is presented by the Broker to the requester, not as the Process Model of the 
selected provider but as the Process Model of the Broker. This makes sense 
since the requester interacts only with the Broker. The new Process Model 
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indicates to the requester what information is needed and in what order. How 
the Broker infers the additional information it needs from the provider and how 
it constructs the new Process Model is presented in Section 6.2. 

The Service Grounding provides a mapping from the semantic form of the 
messages exchanged as defined in the Process Model, to the syntactic form as 
defined in the WSDL input and output specifications. The Grounding provides 
to the Broker the mapping from the abstract semantic representation of the 
messages to the syntactic form that these messages adopt when they become 
concrete information exchanges. The Broker uses this mapping to interpret the 
messages that it receives and compile the messages that it sends to the requester 
or to the provider. 



5. A PROCESS MODEL FOR THE BROKER 

Every interaction between agents using OWL-S must be affected in accor- 
dance with the provider’s Process Model. Interactions with a Broker are no 
exception. Since, from the point of view of the requester, the Broker is the 
provider, it expects the Broker to publish a Process Model that is to be used 
during the interaction. In this section, we show that the Broker’s Process Model 
pushes the boundaries of the current specification of OWL-S. 

5.1 The Broker’s Paradox 

A requester interacts with the Broker using the Broker’s Process Model. The 
Broker’s Process Model should specify how the requester can submit its query, 
but it should also allow the requester to provide any additional information that 
the Broker needs to interact with the provider. Since, to the requester, the Broker 
is (a representative of) the provider, the Process Model of the Broker should 
contain the crucial elements of the Process Model of the provider. However, 
since the Broker is unaware of the provider until it has discovered and selected 
the provider based on a requester’s query, the Broker is faced with a challenge: 
it must publish a Process Model that depends on the provider’s Process Model, 
but the provider is not known until the requester reveals its query. On the other 
hand, the requester cannot query (interact with) the Broker until the Broker 
publishes its Process Model. The result is a paradoxical situation in which 
the Broker cannot reveal its Process Model until it receives the query of the 
requester, but cannot receive the query from the requester until it publishes its 
Process Model. 

Essentially, the Broker’s paradox is due to the fact that the discovery of 
the provider depends on the requester’s query, while the rest of the interac- 
tion between the requester and the Broker depends on the provider selected. 
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Figure 4.2. Broker’s Process Model 



Ultimately, the Broker paradox results from an inflexibility of the OWL-S spec- 
ification of service invocation, which requires the specification of the Process 
Model before the interaction, and does not allow any means to modify the 
Process Model during the interaction. 

5.2 Extending OWL-S Process Model 

The solution of the Broker’s Paradox that we propose requires an extension 
of the specification of the OWL-S Process Model to allow the flexibility to 
dynamically modify an agent’s Process Model during the interaction. As a 
result, the Broker can provide an initial, provider-neutral, Process Model to the 
requester, and then modify it consistently with the requirements of the Process 
Model of the provider. The changes are then adopted by the requester in its 
interaction with the Broker. 

To implement this solution, we propose to extend the OWL-S Model Process- 
ing language by adding a new statement, that we call exec. The exec statement 
takes as input a Process Model and executes it. Therefore, the Broker can 
compile a new Process Model, return it as an output of one of its processes, 
and then use the exec statement to turn the new Process Model into executable 
code that specifies the Broker’s new interaction protocol. 

The provider-neutral Process Model of the Broker is shown in Figure 4.2. It 
shows that the Broker performs a sequence of three operations, where the first 
operation is GetQuery in which the Broker gets the query from the requester. 
The second operation is Discover in which the Broker uses its discovery ca- 
pabilities to find the best provider. The result of the Discover process is a 
new Process Model that depends on the provider found. Finally, the Broker 
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performs the exec operation, which passes control to a new Process Model. 
This change of control is shown in the figure by the three small rectangles that 
display processes that will be run as a consequence of the exec. 

The use of the exec solves the Broker’s Paradox by removing the inflexibility 
of the OWL-S Process Model. The exec operation allows the separation of 
service discovery from service invocation and interaction. First the discovery 
is completed, then the interaction, which depends on the discovered provider, 
is initiated through the exec . 

One important question that is left unanswered is whether there is a clever 
way to use OWL and OWL-S that does not require the extension of the language 
that we propose. Unfortunately, such an extension does not exist, because 
neither OWL nor OWL-S provides a way to transform a term into a predicate 
of the logic, which is the essential step that is performed by the exec. 



6. IMPLEMENTATION 

We have implemented a prototype of a Broker that makes use of OWL-S 
with the exec extension described above to mediate between agents and Web 
services. We based our implementation of the Broker on the OWL-S Virtual 
Machine (OWL-S VM) (18), which is a generic OWL-S processor that allows 
Web services and agents to interact on the basis of the OWL-S description of 
the Web service and OWL ontologies. In the implementation of the Broker, we 
extended the OWL-S VM to include the semantics of the exec. Furthermore, 
we developed the reasoning that allows the Broker to perform discovery and to 
mediate the interaction between the provider and the requester. 

In this section, we analyze how we implemented the different aspects of the 
Broker. We will first discuss the implementation of the discovery process, and 
then we will analyze the modification of the interaction protocol that allows 
the Broker to mediate between the provider and the requester. Finally, we will 
discuss the use of the OWL-S VM in the implementation that allows us to 
actually mediate between the two parties. 

6.1 Supporting Discovery 

The Broker expects from the requester a query in OWL-QL format (10), 
where the predicate corresponds to a property in the ontology, the terms in the 
query are either variables, or instances that are consistent with the semantic 
type requirements of the predicate. 

The discovery process takes as input the query of the requester and generates 
as output the advertisement of a provider (if any is known to the Broker) that 
can answer the query. The discovery process has three steps. First the Bro- 
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ker abstracts from the query to the capabilities that are required to answer that 
query, thus constructing a service request. Second, the Broker finds appropriate 
providers by matching the capabilities requested with the capability advertise- 
ments by the providers. Third, the Broker select the most appropriate provider 
among the providers that match the capabilities requested. The matching of 
the service request against the advertised capabilities was implemented using 
the OWL-S matching engine reported in (19) and (20). 

The automatic abstraction from the requester’s query to a service request 
is, to our knowledge, an unexplored problem. The abstraction process must 
respect the constraints of the OWL-S discovery process, namely generation 
of an OWL-S service profile where the service inputs and outputs reflect the 
semantic content of the query. The abstraction procedure that we implemented 
distinguishes between variables, and the terms that are instantiated in the query. 
Since the result of the query should be an instantiation of the variables, ideally, 
the selected provider agent would take as inputs the instantiated terms and 
return as output an instantiation for the variables. 



1 set V = set of variables in the query 

2 set T= set of instantiated terms in the query 

3 set 1= abstraction of each term in T to its immediate class 

4 use predicate definition in the ontology to abstract variables in V to their 
class 

5 set 0= abstraction of each variable in V to its class 

6 generate a service request with input I and outputs O 



Figure 4.3. The abstraction algorithm 



The instantiation algorithm follows the 6 steps listed in Figure 4.3. In steps 1 
and 2, terms from the query are extracted distinguishing between variables and 
instantiated terms. In step 3, the set of inputs of the service request is derived by 
abstracting the instantiated terms to their immediate class. For instance, if one 
term were Pittsburgh, it would be abstracted to City (assuming the presence of a 
location ontology). Step 4 is needed to handle variables. In OWL-QL variables 
are of class Variable, but there is no constraint on the type that they have to 
assume. We use the definition of the predicate in the ontology to constrain the 
type of the values of the variable to the most restrictive class of values that they 
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can be assigned to. In step 5, we use the abstraction in step 4 to generate the set 
of outputs 0. Finally, in step 6, the service request is generated by specifying 
the inputs and the outputs. 



6.2 Supporting Mediation 

After the Broker has selected a provider, it must mediate between the provider 
and the requester. The mediation process depends on the Process Model of the 
provider which specifies what information is required and when. In theory, the 
Broker may just present to the requester the Process Model of the provider and 
limit mediation to message forwarding. But this solution is unacceptable, since 
it ignores the information that the requester already provided to the Broker. 
For example, the requester may ask the Broker to book a trip to Pittsburgh. 
The Broker may find a Travel Web service that asks for departure and arrival 
location. The task of the Broker is to recognize that arrival location information 
has already been specified so the Broker needs to ask the requester for the 
departure location only. 



1 KB= knowledge from query 

2 1= input of process 

3 for i € I 

4 select k from KB with the same semantic type of I 

5 if k exists 

6 remove i from I 



Figure 4.4. Algorithm for pruning redundant information 



The algorithm for pruning redundant information is shown in Figure 4.4. 
It hinges on removing from processes inputs that should be provided by the 
requester, but that can be filled by the information the Broker already has. First, 
the Broker records the information provided by the query in a KB (step 1), and 
the inputs of the process (step 2). Next for each input i, the Broker looks in the 
KB for information that it can use in place of i. If any is found, i is removed 
from the inputs of a process. 
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Figure 4.5. Broker Architecture 



For example, suppose that the requester’s query asking for the booking of 
a trip used ArrivalLocation=Pittsburgh to indicate the destination of the 
travel. Furthermore, suppose that the Process Model requires two inputs of type 
DepartureLocation and ArrivalLocation. Our algorithm would generate 
a Process Model in which the Broker asks only for first input (the departure city), 
while the second input ArrivalLocation will be pruned by the algorithm 
because it has the same semantic type of the information provided in the query. 



6.3 Managing Message Passing 

The last aspect of the Broker is to instantiate a message passing mechanism 
that allows consistent data transfer between the provider and the requester. 
The architecture of the Broker is shown in Figure 4.5. To interact with the 
provider and the requester the Broker instantiates two ports: a server port for 
interaction with the requester (since the Broker acts as a provider vis a vis the 
requester) and a client port for interaction with the provider (since the Broker 
acts as a client vis a vis the provider). The functionalities of the server port 
are described using OWL-S. Specifically, the Broker exposes to the requester 
its Process Model, Grounding and WSDL specification. The client (requester) 
uses these descriptions to instantiate an OWL-S Virtual Machine to interact with 
the Broker. Since the provider-neutral Process Model exposed by the Broker 
makes use of the exec extension, the OWL-S Virtual Machine used by the 
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requester also implements the axioms that implement the execution semantics 
of exec. The client port is also implemented as an OWL-S Virtual Machine that 
uses the Process Model, Grounding and WSDL description of the provider to 
interact with it. 

The reasoning of the Broker happens in the Query Processor (see Figure 
4.5) that is responsible for the translation of the messages between the two 
parties and for the implementation of the algorithms in Figures 4.3 and 4.4. 
Specifically, the Query Processor stores information received from the query 
in a Knowledge Base that is instantiated with the information provided by the 
requester. Furthermore, the Query Processor interacts with the Discovery 
Engine, which provides the storage and matching of capabilities, when it 
receives a capability advertisement and when it needs to find a provider that 
can answer the query of the requester. 



7. CONCLUSIONS 

Despite the wide use of Brokers in different aspects of distributed systems, 
and despite the many uses Brokers can have in the discovery and mediation 
of Semantic Web services, no detailed analysis of what tasks a Broker should 
perform to support the interaction has been proposed. One contribution of 
this paper is to provide such as analysis. In the course of this analysis, a few 
challenges were uncovered, and solutions for these challenges were presented. 

The first challenge was the “Broker’s paradox”, namely that the Broker 
cannot publish a Process Model that is based on a yet unknown provider before 
it receives a request query, and the requester cannot send a query until it knows 
the Broker’s process Model. This paradox arises from the OWL-S Web service 
interaction specification that requires a declarative specification of a process 
model to guide the requester and provider interaction. To address the Broker 
paradox, we extended the OWL-S Process Modeling language with an exec 
operation that allows the dynamic modification of the Broker’s Process Model 
during its execution to include Process Models of dynamically discovered new 
parties. 

A second set of challenges derives from the management of the mediation 
between the provider and the requester. To address these challenges, we de- 
veloped a method for abstracting from a service query to a service request. 
We proposed an algorithm to address this issue. Furthermore, we used the 
knowledge provided by the requester during the interaction with the provider. 

Crucially, the issues emerging with the mediation between the provider and 
the requester are not unique to Web services Brokering: rather, they arise in 
Web services composition as well. In the context of Web service composition, 
a planner may issue a goal that it wants to subcontract. The task of the Web 
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service is first to abstract from the specific goal to a capability description of a 
provider that can solve the goal, then use its current knowledge, and the goal, 
to interact with the provider. In current research, we are looking to integrate 
our work in the context of Brokering to automated composition. 
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Chapter 5 

AGENT-BASED WEB SERVICES FOR 
INTEROPERABILITY WITH THE WEB- 
CENTRIC ENTERPRISE 
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Abstract: Over the past several years, many legacy applications have become Web- 

enabled. A current trend is to Web service-enable legacy applications to allow 
for XML-based data exchange between a legacy application and a software 
client that could be hosted in a different framework. This approach enables 
interoperability between legacy systems and those developed in frameworks of 
the Web-centric multi-tier architecture that is now prevalent. 

For building agile, loosely coupled systems, a proposed architecture is that 
offered by software agent frameworks. If systems are developed in agent 
frameworks, there will be architectural interoperability issues with Web- 
centric systems. One approach to facilitate agent system / Web-centric system 
interoperability is to utilize Web services as a bridge, with software agents 
offering Webs services to clients of other frameworks. This approach was 
investigated via a prototyping effort, which is reported herein. Attention is 
restricted to software agent frameworks that are compliant with the 
specifications of the Foundation for Intelligent Physical Agents (FIPA). The 
focus is on the principled design and performance of agent-based Web 
services. Recommendations for modifications to FIPA specifications in order 
to increase support for agent-based Web services are also given. 



1. INTRODUCTION 

There is often a need for interoperation between a legacy application and 
one developed in a current framework [17]. Legacy systems range from 
commercial banking systems to command and control systems for the 

1 Current address: Intelligent Automation, Inc. 
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military. Such systems may host multiple applications, each of which can 
interoperate within the confines of the system. New extensions to such 
systems still require information from the legacy elements. For example, 
extensions to command and control systems to support wireless operations 
will require data that is provided by the legacy elements. In the financial 
sector, resources may not exist to re-develop multiple legacy applications 
within a Web-centric, multi-tier architectural framework, such as that 
offered by the Java 2 Enterprise (J2EE) framework [15]. Also, the operation 
and output of a legacy system will have been tested and validated. Generally, 
access to any particular legacy application is through its specifically 
designed client counterpart. Over the past few years, many legacy systems 
have become Web-enabled to allow for browser access to their data. A 
current trend is to Web service-enable legacy systems to allow for XML- 
based data exchange between a legacy application and a software client. 

The software agent paradigm has been put forth as being appropriate for 
the software engineering of complex, loosely coupled systems [13]. While 
there are numerous software agent frameworks discussed in the literature, 
attention is restricted to those compliant with specifications set forth by the 
Foundation for Intelligent Agents (FIPA). The FIPA focus is on the 
development of specifications that promote agent system interoperability. 
As systems are developed that utilize software agents as component building 
blocks [11], it is likely that they will have to interoperate with either legacy 
systems or those developed using a multi-tier, Web-centric framework. One 
possible approach to sharing information products developed within the 
agent system with such other systems and with the larger Enterprise is to 
Web service-enable multi-agent systems (MAS). That is, information in an 
agent-based system would be exposed via Web services. Software clients 
could be browser clients as well software agents, the latter potentially from 
other agent systems. 

The work reported on here presents the issues involved in enabling FIPA- 
compliant multi-agent systems to offer Web services to browser clients of 
the J2EE Web-centric system. The investigation utilized a prototyping 
approach. Objectives include elucidating the design and performance issues 
that are involved in accomplishing this, as well as identifying modifications 
to the FIPA specifications that would render the FIPA-complaint agent 
framework more Web service ‘friendly’. Contributions include identification 
of design patterns, agent roles, and instances in which the FIPA 
specifications could be revised or extended in order to support enabling a 
Web-service capability from the multi-agent system. Results of a 
preliminary performance study are also presented. 

Prior to presentation of the details and results of the investigation, a short 
description of the J2EE and agent frameworks is necessary. This includes a 
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brief discussion of their respective typical usage patterns and existing 
support for Web services. Interoperability issues between frameworks are 
also highlighted. While the results reported herein concern details of Web 
service enabling the FIPA-compliant MAS, it is emphasized that the 
motivation for this work proceeded from the need to develop an 
interoperability approach between Web-centric multi-tier enterprise 
frameworks and agent frameworks. 



2. FRAMEWORK DESCRIPTIONS 

2.1 Major Framework Elements 
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Figure 5-L Contributing Frameworks and Their Constituent Elements 

In order to ground the discussion of interoperability issues between 
systems built utilizing J2EE frameworks, and those built utilizing FIPA- 
compliant agent frameworks, a brief look at the elements of each of these 
frameworks is in order. Figure 5-1 serves to illustrate the elements of the two 
frameworks. The elements of Web service technology are to provide a 
bridge between systems. While these are shown as conceptually distinct 
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from each of the two systems, a Web service could be hosted by either 
system and accessed by clients from both systems. 

2.1.1 J2EE Framework Description and Typical Usage Pattern 

Clients of the multi-tier client-server J2EE framework are browsers, 
applets, or applications. Server tiers are comprised of containers; a Web 
container hosts Web applications developed as servlets, Java Server pages, 
or HTML pages and an Application container hosts the Enterprise Java Bean 
(EJB) components that contain business logic. The J2EE platform offers 
middleware services to its hosted components, as well as a suite of APIs, 
among which are the Java Naming and Directory Interface (JNDI) and the 
Java Message Service (JMS). The backend tier can involve Enterprise 
information systems, databases, or legacy systems. A body of design 
patterns encapsulates best practices for developing J2EE hosted applications 
[ 18 ]. 

A typical usage instance involves a browser client and a J2EE-hosted 
application. The browser client invokes a servlet, which contains the entry 
point to a business application composed of EJBs. The servlet then invokes a 
business method that is contained within an EJB. The EJB obtains 
information stored in a database and returns it to the servlet and thence to the 
client. The sequence of interactions is from tier-to-tier. Method invocation is 
used. Invocations typically have synchronous semantics. 

2.1.2 Web Services Framework and Typical Usage Pattern 

Current Web services technology is typically considered to be given by 
the specifications: (1) Simple Object Access Protocol (SOAP) [21]; (2) Web 
Services Description Language (WSDL) [25]; and (3) Universal Description, 
Discovery, and Integration (UDDI) [22]. SOAP pertains to the message 
format typically used in invoking a Web service, WSDL pertains to both the 
Web service interface and implementation descriptions, and UDDI pertains 
to registry information containing descriptions of the service. A fourth 
technology, that of Business Process Execution Language (BPEL) for Web 
Services [1], a workflow-like language, is concerned with Web service 
composition. 

Implicit in the use of Web services is the need for a SOAP processor that 
performs the details of accessing the object that offers the actual service 
(method). A binding to a service instance must have been given in the 
WSDL description; often this is a URL, as SOAP messages typically are 
sent via HTTP. Typical usage involves browser clients in a Web services 
invocation. One common approach to implementation of a SOAP processor 
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is via servlets on a J2EE platform. The semantics of a request-response Web 
service is similar to that of an invocation on business methods of the EJBs. 

2.1.3 FIFA Agent Framework Description and Typical Usage 
Pattern 

A FIPA-compliant platform [9] offers an Agent Management Service 
(AMS) agent and a Directory Facilitator (DF) agent. Functionally, the AMS 
manages the agent registration on the platform. It offers a ‘white’ pages 
service. The DF agent offers a ‘yellow’ pages service. Software agents that 
wish to offer services to their fellow software agents can advertise these 
services by filling out a FIPA Service Description (SD) and registering it 
with the DF agent. 

Software agents are the components that comprise a particular 
application, which can be viewed as a multi-agent system. Development of 
agents in the MAS is done using, for example, the Gaia methodology [24]. 
Design patterns provide an approach to organizing roles and relationships of 
agents in the MAS. Agent interaction takes place via messaging and follows 
conversational style interaction protocols, which are specified in the 
standards [9]. Messages are expressed in FIPA Agent Communication 
Language (ACL) [9]. Message exchange has asynchronous semantics. 

2.2 Web Services and Framework Interoperability 

Recent work [4] gives a detailed architecture comparison of J2EE and 
FIPA-compliant agent frameworks. Applications, including Web services, 
built in a particular framework will reflect the guiding paradigm, restrictions, 
and infrastructure support of that framework. Yet a given Web service 
should be able to be accessed by a client in either framework. Certain 
framework differences lead to interoperability issues that can impact the 
offering of a Web service across the architecturally heterogeneous systems. 

Consider that the J2EE framework specifications support exposing 
business methods of EJB components as services. The infrastructure 
supports an EJB to act as the endpoint of a Web service. Accessing a Web 
service then follows the patterns for accessing an EJB. The J2EE framework 
is Web services ‘friendly’. In contrast, FIPA standards do not address 
infrastructure support for Web services. FIPA specifications are concerned 
with agent/agent and agent-system/agent-system interoperability; there is no 
consideration of a browser client. 

Recent research [7,8,20] has categorized the impact of system and 
component architectures on interoperability into three areas: (1) system 
characteristics, (2) control characteristics, and (3) data characteristics. We 
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add the additional categories of semantic characteristics and discovery 
characteristics. These categories are useful in structuring an abbreviated 
discussion of interoperability issues. 

Within system characteristics are (1) identity of components, and (2) 
blocking. With regard to identity, software agents in the MAS can be aware 
of other software agents through the use of look-up and discovery that is 
facilitated by the Directory Facilitator agent. In contrast, browser clients are 
unaware of the EJB components that (may) fulfill a Web service request. 
There is no infrastructure support for dynamic discovery of general services, 
the JNDI API notwithstanding. The issue of discovery of a Web service 
hosted in an agent framework is even more acute. This leads into the 
discovery characteristics . Is the discovery of a service assumed to be done 
dynamically , or at design time? Discovery involves a search; what is its 
scope? 

Regarding blocking, typical usage of Web services hosted in a J2EE 
framework is that of request-response. Here, the browser client waits for a 
response. The paradigm in a MAS is that agents engage in asynchronous 
message passing; blocking is atypical. 

Control flow is a control characteristic. In a J2EE application, control 
flow, heavily guided by the framework, is typically from tier-to-tier; the 
Web service is offered by a component in the application tier. In an agent 
system, the control flow is according to the organized roles of agents in the 
MAS, e.g., peer-to-peer. The MAS architecture does not mandate a control 
flow among the agent components. 

The semantic characteristics area speaks to the issue of semantic 
mismatch. This encompasses differences in the semantic levels of message 
content, in the semantic level of component interaction, and in the semantics 
of the supporting infrastructure. Message content in J2EE and Web service 
applications involves a method name with parameters. Message content in a 
MAS involves expressions in a content language, many of which are 
expressive enough to permit logical reasoning. Conversational style agent 
interactions in the MAS are at a different semantic level than method 
invocations used among components in J2EE frameworks or Web services. 
Semantic mismatch can also occur if the different agents and/or J2EE 
components are utilizing different ontologies. 

2.3 Use Case Scenario Grounding the Investigation 

Recall that the primary objective is to provide a mechanism to promote 
interoperability between (applications built in) different systems. The usage 
scenario that motivated this work arose from the following question: “What 
is a good mechanism to expose information that is extant in any particular 
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agent-based application to clients (or components) that are not software 
agents?” If this exposure is considered in terms of a service paradigm, the 
question can be rephrased as: “How can the information that is available in 
any particular agent-based system be offered as a service to clients (or 
components) that are not software agents?” Currently, the primary approach 
to services at the application level is offered by Web services. 

The goal of the prototyping investigation is to establish a principled 
approach by which a FIPA-compliant multi-agent system will offer Web 
services to non-agent clients. 

In order to situate this discussion in a concrete setting; consider an agent- 
based application that generates a ‘Weather Note’ as an information product 
[17]. The ‘Weather Note’ announces weather events of interest, such as the 
onset of fog at a given location or the potential for icing, etc. Various 
software agent components must work together to produce the ‘Weather 
Note.’ These include agents whose task it is to acquire raw weather data, 
those that are tasked with decoding the raw data and those which organize it 
into mini-weather reports. Middle agents are needed to organize the mini- 
weather reports by categories, such as geographical regions or time. An 
agent that can reason on weather report information is needed to produce the 
‘Weather Note.’ Such notes are produced asynchronously. 

Leveraging an agent-based application requires rendering the information 
it ‘contains’ accessible to additional systems and their applications. For 
example, a logistics system might require precipitation and temperature 
information at various points along a route. Information at this level of 
granularity could be made available via a Web service capability provided 
by the agent system. 



3. A PRINCIPLED APPROACH TO AGENT-BASED 
WEB SERVICES 

3.1 Design Patterns and Agent Roles 

Design patterns can be utilized in the development of a multi-agent 
system that is organized so as to offer agent-based Web services to agent 
clients and clients of other frameworks. The guiding principle is one of 
minimizing the number of agents that are required to know Web service 
specific information. 
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Table 5-7. Architectural Patterns Supporting Agent-based Web Services 



NAME 


Gateway Pattern 


Web Service Layer Pattern 


CONTEXT 


Web service requests are 
made by browser clients. 
These requests are to be 
satisfied by software agents 
residing in a FlPA-compliant 
MAS. 


Specific agents within the 
FlPA-compliant multi-agent 
system will respond to 
requests for a Web service. 


PROBLEMS(S) 


The browser client of the 
J2EE system does not know 

(1) how to find the software 
agent is offering a service, 

(2) how to send a message to 
the software agent that is 
offering a service, or (3) how 
to communicate with the 
software agent (semantic 
mismatch). 


Avoid re-engineering of 
software agents built 
previously to perform part of 
an agent-based application in 
order to satisfy a Web 
service request for 
information. 


SOLUTION 


Gateway is a single focus for 
Web service requests 
(responses) to enter (leave) 
the multi -agent system from 
another framework. 


Provide a new ‘layer’ of 
agents in the multi-agent 
system that offers specific 
agent-based Web services. 



Design patterns can apply across a range of abstractions and scope, from 
designs that are useful within a particular programming language to designs 
that serve to organize software sub-systems to those that address software 
architecture. From [3], an “architectural pattern expresses a fundamental 
structural organization schema for software systems. It provides a set of 
predefined subsystems, specifies their responsibilities, and includes rules and 
guidelines for organizing the relationships between them.” More recently, 
Hayden and colleagues [12] considered design patterns for agent systems to 
support agent coordination. 

In this work, two architectural design patterns for multi-agent systems 
in support of agent-based Web services were identified. These are the (1) 
Gateway design pattern, and the (2) Web service layer design pattern. A 
standard presentation of a pattern involves a description of its context, 
problem and solution. This is given in Table 5-1. 

These architectural design pattern solutions were realized by defining 
specific agent roles in the multi-agent system, the roles of a Web Service 
Agent and of a Gateway Agent. The features of these roles are given in 
Table 5-2. In this particular implementation, the Gateway agent addresses 
the semantic mis-match interoperability by offering translation services. 
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Table 5-2. New Agent Roles in Support of Agent-based Web Services 



Agent Roles 



Agent Responsibilities 



Resources Needed 



Web Service Agent 
( Multiple Web service 
agents were instantiated. ) 



-Offer service via FIPA 
Request interaction 
-Participate in the external 
Web services framework by 
(1) registering the necessary 
service information with the 
DF, (2) by ‘filling out’ an 
agentized WSDL file and 
hosting it at an accessible 
Web site, (3) by knowledge 
of Gateway -out agent. 
-Send responses to requests 
that originate from Gateway 
In agent to Gateway Out 
agent. 

-Propagate request ID on 
exchanges within MAS. 



-The weather information. 
-Knowledge of protocols that 
will allow agent to interact 
with agents in the MAS that 
have the detailed information 
(e.g., on weather). 



Gateway Agent 
(A Gateway-In and a 
Gateway-Out agent were 
instantiated.) 



-Process incoming or out- -JMS Connections, 
going JMS message. -SOAP- JMS Binding 

-Extract SOAP content from software. 

JMS message or construct 
SOAP content for JMS 
message. 



Translation Agent 
(Not implemented directly in 
this work , functionality 
moved to Gateway Agents.) 



- Translate SOAP message 
content to FIPA agent 
content language message 
and reverse. 



Translation resources. 



In this work, SOAP messages initiated by the browser client were 
restricted to simple request-response types, resulting in a simplification of 
the translation needs. SOAP message content is translated into ACL message 
content, expressed in FIPA SLO, by the Gateway-In agent. (A Gateway-Out 
agent performed that reverse translation as part of returning the response.) 

The responsibilities of the Web service agents include a need for them to 
participate in the ‘external Web services framework’. This phrase denotes an 
instantiation of the Web services technologies for the purpose of offering 
Web service capabilities within an organization, with ‘external’ indicating 
that certain crucial components of this capability are not within the agent 
system. These include the UDDI registry, the BPEL engine, and WSDL 
files. 
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3.2 Flow of Control and Framework Interoperability 

The earlier section discussed the nature of flow of control within the two 
different frameworks. However, in order for a software agent to offer 
services to a browser client, the flow of control must cross into, and return 
from, the multi -agent system. To this end, a ‘connection framework’, 
consisting of architectural components from the J2EE system and from the 
multi-agent system, was defined. From the J2EE system, the connection 
element is the SOAP processor, which is implemented as a servlet 
component. The Gateway is the element contributed to the ‘connection 
framework’ by the multi-agent system; it was implemented as two Gateway 
agents. See Tables 5-2 and 5-3. 

Both discovery and blocking issues are system characteristics pertaining 
to architectural interoperability. The J2EE framework does not offer Web 
service discovery support - but this capability is necessary in order to use 
Web services technology as a bridge between the J2EE and FIPA-compliant 
agent frameworks. While the focus of this paper is on rendering agent 
systems Web service ‘friendly’, nonetheless, the prototype investigation has 
revealed a weakness of the J2EE framework. In the prototype, dynamic 
discovery of Web services registered in the (local) UDDI registry is a 
capability that is built into the aforementioned servlet. 

Although the browser client in the J2EE system engages in blocking 
while waiting for a response, communications within the agent system are 
asynchronous. The ‘connection framework’ provides a bridge: 
communications into the agent system from the servlet utilize Java Message 
System (JMS) transport, an enterprise messaging service of the J2EE 
framework. With this, JMS messages carrying SOAP content are passed into 
the agent system over a JMS topic channel. The Gateway agents, listening 
on the topic channels, receive the SOAP requests carried as JMS message 
content. 

Figure 5-2 aids in visualizing the request thread from the client browser 
into agent system. The name of the Web service agent that is the ultimate 
destination for the browser client’s request is known from agentized WSDL 
file information: found from UDDI registry information, it is the value of the 
destination property set in the JMS message. This JMS message hosts the 
SOAP request that travels into the FIPA-compliant agent system. The servlet 
functionality is to access the UDDI registry and WSDL file, construct the 
SOAP message as content to the JMS message, and publish the JMS 
message, which travels into the FIPA-compliant agent system. 
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Table 5-3. Components of the Connection Framework 





SOAP PROCESSOR 


GATEWAY 

IMPLEMENTATION 


Implementation Approach 


Servlet 


Gateway-In Agent 
Gateway-Out Agent 


Host Framework 


J2EE Platform 
(Web Logic V7.1) 
[23] 


FIPA-compliant multi-agent 
system platform 
(FIPA-OS) [10] 


Major Implementation 


SOAP Binding to JMS. 


SOAP message extraction 


Features 


(Software to facilitate the 
creation of the SOAP request 
and response messages as 
JMS content.) 


(into) and construction (out 
of) MAS. 

ACL message formulation 
(into) 

Translation software (in this 
prototype implementation 
only) 



Within the agent system, the Gateway agent translates the SOAP 
message into an FIPA ACL message for the destination Web service agent, 
and constructs the message content. The Web service agent interacts with 
other agents in the MAS is via the FIPA Request Protocol. After the Web 
service agent has gathered information necessary to satisfy the Web service 
request, it composes a response and sends it to the Gateway (out), which 
constructs a SOAP reply message as content to a JMS messages. The JMS 
message is published on a topic channel, and is ultimately received by the 
servlet. Note that the connection from the browser client to the servlet must 
be kept alive for a ‘reasonable’ amount of time in order to allow the agent- 
based Web service to provide its response. Also note that both blocking and 
non-blocking communications are needed to obtain the response for the 
browser client. 
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Figure 5-2. Connection Framework Elements Shown in Relation to the J2EE Platform and the 
FIPA-complaint Multi-agent Platform 



3.3 Extending the FIFA-compliant Agent Platform 

It would be burdensome for each Web service agent to access the UDDI 
registry and insert its respective advertisement entries. An infrastructure 
agent, the Registration agent, capable of registering these agents’ respective 
services in the UDDI registry would be useful. Similarly, each Web service 
agent should not be responsible for receiving the SOAP message, parsing it, 
and understanding its content. The same Web service agents would also have 
to understand requests for information expressed in at least one agent 
content language. Specialized Translation agents are useful. 

This investigation has focused on simple agent-based Web services. In 
the general case, a Web service may be constructed by composing simple 
Web services. This is the function of a BPEL execution engine in the 
standard Web services technology suite. The BPEL technology suggests a 
new agent role, that of a Web Service Orchestrator agent. Consider a ‘static’ 
Web Service Orchestrator agent; it knows its constituent agent-based 
services. This agent would register the description of its (composed) service 
with the Directory Facilitator agent. Note that necessary specifications for a 
‘dynamic’ Web Service Orchestrator agent are the subject of current 
research. See Charlton and Ribiere [6] for a discussion. 
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The Orchestrator agent role is consistent with the Web service layer 
design pattern. It can be viewed as simply another agent in the Web service 
agent layer. However, it would interact with other Web service agents 
instead of the middle agents that hold, say, the weather information. These 
other Web service agents would provide intermediate results that the 
Orchestrator agent fashions into the answer. The Orchestrator agent would 
communicate with the Gateway agents just as the other agents in the Web 
service layer do. 



Table 5-4. Agent Platform Extensions to Support Agent-based Web Services 



Platform Services 
(Realized via Agents) 


Agent Responsibilities 


Resources Needed 


UDDI Registration Agent 


-Dynamically harvest 
descriptions of agent-based 
Web services. 

-Register the services in the 
UDDI registry, if not already 
registered. 


-Service Description 
information that is registered 
with the DF. 

-Encapsulates knowledge of 
how the tag information and 
certain properties are to be 
used in the UDDI 
registration process. 


Web Services (Static) 
Orchestrator Agent 

(Designed but not 
implemented ) 


-Encapsulate context for a 
composed Web service. 
-Discover and communicate 
with Web service agents to 
fulfill a request. 

- Web service agent 
responsibilities vis-a-vis 
external framework. 


-Knowledge of context for a 
composed Web service. 

- Access to the DF agent 
-Knowledge of protocols that 
will allow agent to interact 
with Web service agents in 
the MAS. 



Note that the platform extensions shown in Table 5-4 are software agents 
themselves. This is consistent with the FIPA treatment of the Agent 
Management Service and the Directory Facilitator. (The Translation agent 
appeared in Table 5-2, and is not repeated here.) 

Clients of a Web service agent can include other software agents as well 
as browser clients (via the J2EE system). A Web service agent must 
advertise its service in both the UDDI registry (for non-agent clients) and 
with the Directory Facilitator (for agent clients). In the FIPA-compliant 
multi-agent system, an agent can register its service(s) with the Directory 
Facilitator agent by providing a FIPA Service Description [9]. 

Ideally, the FIPA Service Description (SD) that a Web service agent 
provides contains sufficient information for both Directory Facilitator entries 
and UDDI entries. The same set of information should allow the service to 
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be registered in the different venues. The service information content should 
also be useful for construction of a Web service agent’s WSDL file. 

In the prototype implementation, the construction of a FIPA Service 
Description (SD) was performed in an ad hoc, yet structured, manner. Full 
use was made of the FIPA Property Template data structure, a sub-element 
of the SD, to allow for {name, value} pairs. The information relevant to 
Web-services includes: 

• Tags that indicated the agent is offering a Web service that should be 
registered in the UDDI; 

• Information where the WSDL interface and implementation files are 
hosted; 

• Keyword information, which may be derived from an ontology, 
indicating the type of service. 

The information in the FIPA Service Description is mined by the 
Registration agent. It must understand how certain properties in the FIPA 
Service Description are to be used in the UDDI registration process. A more 
radical restructuring of agent platform resources to support agent-based Web 
serves would be to develop a more sophisticated Directory Facilitator agent 
that would know what types of entries pertain to Web services, and that 
would export its information in response to a Web service query. This option 
was not investigated in the current work. 

Software agents within the FIPA-compliant multi-agent system can also 
wrap an ‘external’ Web service that then can be offered to other agents. 
These agents would be part of the Web service layer. 

Appropriate elements of the particular WSDL file(s) and UDDI registry 
entries must first be mapped to a FIPA Service Description before the 
wrapper agent could register with the Directory Facilitator. This case offers 
added impetus for elucidating and standardizing a mapping of Service 
Description information to that required by UDDI and WSDL and vice 
versa. As part of the Service Description, the wrapper agent must specify the 
ontology and FIPA Interaction protocol, for other agents to effectively 
communicate with it. The wrapper agent must be able to utilize the content 
of requests from other agents to build the SOAP message in order to invoke 
the external Web service; Translation agents are useful here. 



3.4 Suggested Modifications to FIPA Standards 

With regard to issue of supporting agent-based Web services, 
modifications made to the FIPA specifications in the following areas would 
be helpful: 
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• Modification of the FIPA Service Description data structure to 
encompass all information necessary to ‘fill out’ UDDI Registry 
entries and to create agentized WSDL files; 

• Extension of the FIPA platform architecture by mandating a UDDI 
Registration Agent; 

• Extension of the FIPA platform architecture by mandating SOAP 
translation agents; 

• Extension of the FIPA platform architecture by mandating static 
Orchestration agents; 

• Extension of the FIPA transport services to offer a SOAP transport. 
Note that the SOAP binding can be to other than HTTP. In this work, 
a JMS binding was utilized. 

The new platform infrastructure implies a specialization of a generic 
FIPA-compliant agent platform to one that directly supports agent-based 
Web services. 

3.5 Preliminary Performance Results 

In this prototyping effort, it is the middle agents in the ‘legacy’ agent- 
based application which hold the information to be exposed by the Web 
service agents. The Web service agents must discover and communicate 
with these middle agents, and obtain relevant weather information at the 
level of granularity for the (Web) service that is offered. In the 
implementation, Web service agents interact with a minimal number of other 
software agents in order to obtain the information needed to offer its service. 
This is termed a ‘shallow,’ as opposed to a ‘deep,’ agentized Web service. 

The prototype effort was limited to a study of ‘shallow’ agent-based Web 
services, and one browser client. The implementation involved components 
of the J2EE system (servlets, EJBs), components of the FIPA-compliant 
multi-agent system (various agent types), and additional software such as the 
SOAP-JMS binding. Unless specifically stated otherwise, all components 
discussed were prototyped. Additional resources such as a UDDI registry, a 
BPEL engine [2], and a JMS service were part of the prototyping 
infrastructure. Measurements made on the prototyped systems were utilized 
in developing a Colored Petri Net (CPN) [14] model of the ‘hybrid’ system. 

The ‘hybrid’ system is the term given to the J2EE framework elements, 
the FIPA-compliant multi-agent framework elements, and the infrastructure 
elements. The motivation for developing the CPN model of the ‘hybrid’ 
system was to provide a simulation capability in order to investigate 
additional use case scenarios without the need for prototyping. These use 
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cases typically involve multiple browser clients; each making multiple Web 
service requests that are satisfied by Web service agents. 

A detailed description of the model and results of a study on the wait 
times that the (browser) clients experienced are given in [19]. Here, the 
effect of job complexity, whether ‘deep’ or ‘shallow’, of the agent-based 
Web services on performance time is reported. 



Shallow vs Deep Agentized Web Services 




Number of FIPA REQUEST Conversations per User Query 

Answers 

Messages 

Figure 5-3 . Responses to user requests per unit time. Results are given for ’deep' versus 
'shallow* agent-based Web services 



The client contacts the servlet in the J2EE system to initiate a request for 
information (the answer). The flow of processing of the request begins with 
the servlet, which then sends it to the gateway system, whereupon it is 
ultimately delivered to the appropriate Web service agent. As the number of 
agent system conversations necessary to fulfill a request increases with the 
’deeper* services, the number of answers that can be generated for the client 
per unit time drops. All agent conversations employ the FIPA Request 
interaction protocol. For this simulation, the particular sequence of FIPA- 
standard communicative acts that comprises one branch of the FIPA Request 
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Interaction protocol is ‘request-agree-inform.’ Thus, each request 
conversation involves three messages. The leveling off, observed in Figure 
5-3, occurs when the modeled message transport resource reaches 100 
percent utilization. (Resource limitations in the Colored Petri Net model 
reflect limitations of the products used in the prototyping infrastructure 
[19].) This has implications for capacity planning for Web services that are 
agent-based. 



4. CONCLUSIONS 

The need for applications hosted in different frameworks to interoperate 
is the motivation for this work. Web services technology is already 
providing the interoperability bridge among legacy applications and those 
developed for the J2EE application framework. 

The effort reported in this paper has investigated the issues involved in 
extending, in a principled manner, the Web service framework into multi- 
agent systems so that software agents can offer Web services to non-agent 
clients. Development of agent-based Web services allows non-agent clients 
of diverse frameworks to access information extant in the agent system. 

A design principle of placing a minimum burden on individual 
(application) agents within the multi-agent system was followed. With this 
guiding principle, architectural design patterns for supporting agent-based 
Web services were developed. These include the Gateway pattern and the 
Web service layer pattern. New agent roles that support agent-based Web 
services were identified. 

A Colored Petri Net model of the ‘hybrid’ (J2EE and FIPA-compliant 
agent) system elements that are involved when a browser client makes a 
request of an agent-based Web service was developed. This model was used 
to explore performance of agent-based Web services being offered to non- 
agent clients in a richer set of use cases than could be prototyped. 
Preliminary performance results were obtained. 

The prototyping effort reported herein has resulted in identification of 
useful services that an agent platform could provide in order to facilitate 
offering agent-based Web services. Suggested modifications to FIPA 
specifications in order to support such a Web services ‘friendly’ multi-agent 
system were given. 
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Abstract: This paper introduces a version of KAoS Semantic Policy and Domain 

Services that has been developed to support Web Services-based (i.e., OGSA- 
compliant) Grid Computing Architectures. While initially oriented to the 
dynamic and complex requirements of software agent applications, KAoS 
services are now being extended to work equally well with both agent and 
non-agent clients on a variety of more general distributed computing 
platforms. The OGSA-compliant version of KAoS services allows fine- 
grained policy-based management of registered Grid services as well as 
opening additional opportunities for the use of agents on the grid. 



1. INTRODUCTION 

Despite rapid advances in computing technology, the demanding 
requirements of the science and business communities continue to outstrip 
available technology solutions. To help close this gap, both communities 
have attempted to more fully harness the power of distributed resources 
through sharing and coordinated use. Grid Computing, Web Services, and 
agent-based systems each attempt to address areas in this problem space, and 
they all share the problem of how to manage dynamic, heterogeneous, 
distributed resources. Typically, administrators develop “policies” to 
manage these resources, but these “policies” are usually little more then text 
files used to manage user accounts. The OGSA-compliant version of KAoS 
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services allows fine-grained policy-based management of registered Grid 
services through semantically rich policies. It also allows for dynamic run- 
time changes to those policies. Before discussing the integration details, the 
next sections provide some background information. 

1.1 Grid Computing and Web Services 

Since its inception in the mid-1990’s, Grid Computing has been focused 
on the need for a distributed computational infrastructure that supports 
resource sharing and coordinated problem solving across geographically 
distributed organizations [16]. Grid researchers envision people and 
resources from different institutions being gathered to form Virtual 
Organizations to address complex problems that require extensive 
collaboration and various instruments. Such Virtual Organizations can grow 
to a very large size to encompass multiple institutions, each with their own 
sets of heterogeneous resources. Some successful research efforts consistent 
with this approach in the Grid Computing world are the NASA Information 
Power Grid (IPG) [21] and the EU DataGrid [17]. 

Recently, Grid Computing and Web Services have started to merge. The 
goal of the Web Services effort is to provide infrastructure for services to be 
advertised, found, and accessed over the Internet using Web-style protocols. 
Web Services and Grid Computing face many similar challenges: 
description and advertisement of services, description and matchmaking 
(lookup) of service requests, invocation of services (possibly with attached 
contracts regarding quality of service or other constraints), and the 
accounting mechanisms to charge for resource usage. Recognizing the 
overlap, the Globus group has announced the Open Grid Services 
Architecture (OGSA) [14] that brings Grid Computing services and Web 
Services infrastructures even closer together. 

OGSA defines a Grid service as a Web service that implements a set of 
standard WSDL port types that facilitate service lifetime management, 
service discovery, and other features [14]. Whereas Web Services will 
provide an infrastructure for Grid Computing, Grid Computing expands and 
enhances available Web Services in OGSA, providing a high performance 
infrastructure for demanding applications [10]. For example, while a typical 
Web transaction today involves only a small number of hosts, Grid 
Computing applications routinely incorporate large numbers of processes 
tightly interacting in a coordinated fashion. 
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1.2 Semantic Grid and Semantic Web Services 

Early work in computational grids differed from agent-based systems in 
scope, features, capabilities, and target application domains, with the goals 
for Grid Computing being closer to traditional distributed systems. However, 
recent work on Semantic Grid [11] and Semantic Web Services [12,22] 
architectures aims to support more dynamic, late-binding, and long-lived 
applications, making both platforms better-suited as platforms for multi- 
agent systems. Approaches such as semantic matchmaking that traditionally 
have been exclusively agent-oriented capabilities are also being 
incorporated. 

From the perspective of Semantic Web Services, the aim is to continue 
the transition of the Web from its initial role as a repository of text and 
images to a fully capable provider of services that can be effectively used 
not only by people but also by software agents [22]. Semantic Web 
Languages such as DAML+OIL and its successor OWL extend RDF to 
allow users to specify ontologies composed of taxonomies of classes and 
inference rules. Extending the initial use of the Web by people, agents will 
increasingly use the combination of semantic markup languages and 
Semantic Web Services to understand and manipulate Web content in 
significant ways; to discover, communicate, and cooperate with other agents 
and services; and, as described in this paper, to interact with policy-based 
management and control mechanisms. 

From the point of view of the Semantic Grid, the thrust is to use the 
Semantic Web fabric to represent grid metadata, both to drive the machinery 
of the grid fabric, and for knowledge-intensive grid applications involving 
collaboration between people, such as e-Science. While Grid Computing has 
traditionally been focused on computation, the ambition is to use a richer 
semantic infrastructure to focus on issues of inference, proof, and trust in the 
service of knowledge acquisition, use, retrieval, updating, and publishing 
needs of distributed teams of people [10]. 

1.3 Resource Management and Access Control 

Resource management and access control constitute crucial components 
of the Grid by both guaranteeing the quality of service and preventing 
unauthorized use of resources. Although much progress has been made on 
the integration of dynamic, distributed, heterogeneous resources, there has 
been less focus on the management of them. Most Grid Computing 
environments manage resources in a manner that is similar to network 
administration. Users or groups of users are granted specific permissions on 
specific resources and these permissions are maintained in some kind of 
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database. There are slightly more sophisticated administration techniques 
that handle complex inter-system permissions with trust relationships, but 
these types of solutions do not provide much scalability or flexibility. Simple 
solutions may be acceptable for a stable, benign environment, but in an 
open, dynamic, and potentially hostile environment, such approaches 
quickly become unmanageable. 

Similarly, in the rest of the Web Services world, standards for SOAP- 
based message security and XML -based languages for access control (e.g., 
XACML) have begun to appear. As we explain in more detail in Section 5, 
the immaturity of the current tools along with the limited scope and 
semantics of the new languages make them less-than-ideal candidates for the 
sorts of sophisticated Web-based applications its visionaries have imagined 
in the next ten years [12]. 

1.4 KAoS Introduction 

KAoS services and tools allow for the specification, management, 
conflict resolution, and enforcement of policies within the specific contexts 
established by complex organizational structures represented as domains. 
While initially oriented to the dynamic and complex requirements of 
software agent applications, KAoS services are now being extended to work 
equally well with both agent and non-agent clients on a variety of more 
general distributed computing platforms. The OGSA-compliant version of 
KAoS services allows fine-grained policy-based management of registered 
Grid Computing services. Now that we have developed an initial approach to 
use KAoS in conjunction with OGSA, we are working to generalize it so as 
to work with any Web Service. 

The Globus Toolkit was chosen as the target implementation due to its 
popularity and its desire to conform to an open standard (Open Grid Service 
Architecture) based on Web Services. The need for better tools to manage 
Grid Computing environments is evidenced by the Globus Project’s work to 
incorporate the Community Authorization Service (CAS; see Sections 5.2 
and 5.3). The integration of KAoS services to manage Grid Computing 
services demonstrates how KAoS can be generalized to serve non-agent 
clients and platforms. 

The conformance of version 3 of the Globus Toolkit (GT) to open Web 
Services standards coupled with the increasing trend toward richer semantics 
and powerful policy and domain services presents additional opportunities 
for agents on the grid. For example, we are exploring ways of adapting 
Globus to serve as an alternative substrate to FIPA platforms as the basis for 
AgentCities implementations. The use of KAoS policy and domain services 
provides protection from buggy, poorly designed, or malicious agents and 
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traditional software components, reducing the risk of those who want to mix 
agent and non-agent implementations indiscriminately. We believe this 
synergy is beneficial to both the agent and Grid Computing communities. 

In this paper, we provide an overview of the Globus Toolkit (Section 2), 
a brief description of KAoS (Section 3), and a discussion of our integration 
of the two (Section 4). We follow this with a discussion of related work 
(Section 5) and a final section presenting conclusions and future work 
(Section 6). Throughout the paper we will reference our Whiteboard Grid 
Service. This service provides clients the ability to read from or write to a 
file maintained by the Grid Service and is used to demonstrate various 
concepts. 



2 . GLOBUS OVERVIEW 

The Globus Project has developed the Globus Toolkit (GT) to provide a 
standard set of services with which to build computational grids and grid 
applications [13]. The GT has very specific implementations for directory 
services, resource management, security, and other areas. The most recent 
release, GT 3.0a, incorporates major infrastructure changes. It merges the 
Grid and Web Service technologies into an Open Grid Service Architecture 
(OGSA) [14]. A Grid service is a Web service that conforms to a set of 
conventions (interfaces and behaviors) that define how a client interacts with 
a Grid service [30]. The Grid service specification depicts three alternatives 
for grid service implementation, as shown in Figure 6.1. 




Figure 6. 1 Alternative grid service implementations 
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The first alternative, labeled ‘‘(1)” in Figure 6.1, shows the entire Grid 
service being encapsulated within an executable. The second alternative 
shows a grid service that is completely managed by a container. A container 
provides a complete Java Runtime Environment in which Java code can run 
and makes this environment accessible on the Web. The third alternative 
depicts a container-managed grid service that provides an interface to an 
executable external to the container. The third approach is the architecture 
used during this project. For a more detailed description of grid services the 
reader is directed to the Grid Service Specification [30]. 




Figure 6.2 A computational grid security architecture [15] 

The Globus Toolkit advertises itself as a set of components that 
implement basic services for security, resource location, resource 
management, and other things [13]. Each component is designed to be 
independent of the others to allow for incremental integration. The GT 
provides security through the Grid Security Infrastructure (GSI). It is based 
on Public Key Infrastructure (PKI) and uses authentication credentials 
composed of X.509 certificates and private keys [31]. In brief, a GSI user 
generates a public -private key pair and obtains an X.509 certificate from a 
trusted entity called a Certificate Authority (CA). These credentials then 
form the basis for authenticating the user to resources on the Grid [31]. 
Figure 6.2 depicts the GT authentication process. 

The general process involves the user generating a temporary proxy and 
delegating the user’s rights to the proxy. The proxy is only able to access 
resources where the user has already been granted access. This requirement 
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for each user to map their global credentials to a local account causes both 
an administration headache and scalability problem. The Globus Project tries 
to address this with the addition of the Community Authorization Service 
(CAS; see the section on related work, sections 5.2 and 5.3). 



3. KAOS OVERVIEW 

KAoS is a collection of componentized services compatible with several 
popular agent and distributed computing frameworks, including Nomads 
[27, 28], the DARPA CoABS Grid [19], the DARPA ALP/Ultra*Log 
Cougaar framework [20], Brahms [26], CORBA [33] — and now GT3. While 
initially oriented to the dynamic and complex requirements of software agent 
applications, KAoS services are not restricted to that environment. The 
adaptability of KAoS is due in large part to its pluggable infrastructure based 
on Sun’s Java Agent Services (JAS) [1]. For a full description of KAoS, the 
reader is referred to [3, 4, 5, 6, 7], 

3.1 KAoS Domain Services 

KAoS domain services provide the capability for groups of agents, 
people, resources, and other entities to be structured into organizations of 
domains and sub-domains to facilitate policy administration. Domains may 
represent any sort of group imaginable, from potentially complex 
organizational structures to administrative units to dynamic task-oriented 
teams with continually changing membership. Membership in a given 
domain can extend across host boundaries and, conversely, multiple domains 
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can exist concurrently on the same host. Domains may be nested indefinitely 
and, depending on whether policy allows, membership in more than one 
domain at a time is possible. Figure 6.3 shows a small domain example 
demonstrating the hierarchical structure. 



3.2 KAoS Policy Services 

KAoS policy services allow for the specification, management, conflict 
resolution, and disclosure of policies within domains. Policies are 
represented in DAML (DARPA Agent Markup Language) as ontologies. 1 
The KAoS Policy Ontologies (KPO) distinguish between authorizations (i.e., 
constraints that permit or forbid some action) and obligations (i.e., 
constraints that require some action to be performed, or else serve to waive 
such a requirement) [8]. Only authorization policies are supported in the 
current KAoS GT3 implementation. Through various property restrictions in 
the action type, a given policy can be variously scoped, for example, either 
to individual agents, to agents of a given class, to agents belonging to a 
particular group, or to agents running in a given physical place or 
computational environment (e.g., host, VM). This project broadens the range 
of KAoS beyond agents to include grid clients and services. 

3.2.1 Policy Language 

KAoS uses DAML 1 to represent policies in a semantically rich manner. 
DAML is a Description-Logic-based language that allows for the 
development of a detailed ontology. The current version of the KAoS Policy 
Ontologies (KPO) defines basic ontologies for actions, actors, groups, 
places, various entities related to actions (e.g., computing resources), and 
policies. There are currently 79 classes and 41 properties defined in the basic 
ontologies. It is expected that for a given application, the ontologies will be 
further extended with additional classes, individuals, and rules. For example, 
Grid services can extend KPO concepts with domain specific concepts. 
These extensions can then be dynamically loaded at registration or as needed 
at other times. Figure 6.4 is a visual depiction of the ontology extension 
developed for a Whiteboard Grid Service used to test our integration. KAoS 
uses the Java Theorem Prover (JTP) to reason about the ontology. It can, for 
example determine that a “SignedWriteAction” is a subclass of a 
“GridRequestAction.” Using the domain structure from Figure 6.3, which is 



1 We plan to adopt OWL, the W3C evolution of DAML, once the representation and tools are 
sufficiently mature. 
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automatically generated and dynamically added to the ontology, the system 
can determine that “KAoS-Team-Members” are “IHMC-Employees”. This 
type of reasoning provides a very powerful policy mechanism. 




Figure 6.4 Ontology extension developed for Whiteboard Service 



3.2.2 Policy Creation 

The use of DAML as a policy representation enables runtime 
extensibility and adaptability of the system, as well as the ability to analyze 
policies relating to entities described at different levels of abstraction. The 
representation facilitates careful reasoning about policy disclosure, conflict 
detection, and harmonization, and about domain structure and concepts. The 
representation richness provided by DAML comes with the cost of decreased 
readability to human users. This cost can be mitigated through the use of 
effective interfaces. 

The KAoS Policy Administration Tool (KPAT 2 ) implements a graphical 
user interface, shown in Figure 6.5, to policy and domain management 
functionality. It has been developed to make policy management easier for 
administrators without requiring extensive training. Alternatively, trusted 
infrastructure components may, if authorized, propose policy changes 
autonomously or semi-autonomously based on their observation of system 
events. 



2 Pronounced KAY-pat. 
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To create a policy that controls access to our Whiteboard Grid Service, 
we would simply select the individual or group from the domain view. Next 
we chose and action and associated properties and then specify weather we 
wanted to authorize or forbid this action for the selected users. After the 
policy is complete, it is committed and automatically distributed as 
discussed in the next section. 
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Figure 6.5 KPAT graphical interface for creating policies 



3.2.3 Policy Distribution and Disclosure 

To handle policies in a distributed manner, KAoS introduces a Guard. 
The KAoS system instantiates the Guard into the local Java virtual machine 
during start up. The Guard acts as an intermediary in the registration 
process. When an agent registers via a Guard, all policies that pertain to that 
agent will be distributed automatically by KAoS to the associated Guard. 
When an action is requested, the Guard is automatically queried to check 
weather the action is authorized based on the current policies and, if not, the 
action is prevented by various enforcement mechanisms. Policy enforcement 
requires the ability to monitor and intercept actions, and allow or disallow 
them based on a given set of policies. While the rest of the KAoS 
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architecture is generic across different platforms, enforcement mechanisms 
are necessarily specific to the way the platform works. 



4. INTEGRATION OF KAOS AND GLOBUS 
TOOLKIT 3 

Globus provides effective resource management, authentication and local 
resource control for the grid computing environment, but has a need for 
domain and policy services. KAoS is a perfect complement to the Globus 
system. KAoS provides very rich policy management capabilities, but 
requires platform-specific enforcement mechanisms. The feasibility of 
leveraging the strengths of each became apparent with the recent move by 
the Globus Project toward standardization through the use of OGSA- 
compliant services. By providing an interface between the Globus Grid and 
KAoS, we enable the use of KAoS services to manage GSI enabled Grid 
services. GSI was the only component of the GT we used in the integration. 
The interface itself is a Grid service, which we called a KAoS Grid service. 
It provides Grid clients and services the ability to register with KAoS 
services, and to check whether a given action is authorized or not based on 
current policies. The basic architecture is shown in Figure 6.6. 
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4.1 Creating a KAoS Grid Service 

In order to create a KAoS Grid service, we used tools provided with GT3 
to create a normal Grid service and then added to it the required KAoS 
framework components to make it KAoS aware. This framework links Grid 
service to the KAoS-implemented JAS services: naming, message transport, 
and directory. It also associates a Guard with the KAoS Grid Service. 

4.2 Registration 

To use domain services, we needed to establish a method for clients and 
resources to register within a KAoS domain. The clients or resources contact 
the KAoS Grid Service and use their credential to request to be registered 
into one or more domains. The credential is a standard X.509 certificate that 
Globus uses for authentication. The credential is verified using GT GSI. If 
the certificate is valid the registration request is sent to KAoS for registration 
into the desired domains. If the resource uses a domain specific ontology, it 
will have to be loaded into the KAoS ontology using a utility provided by 
KAoS. Inside the KAoS Grid service, the registration is handled through the 
associated Guard. This allows KAoS to distribute all applicable policies to 
the appropriate Guard. In our Whiteboard example, both the Whiteboard 
service and the Whiteboard client register with the KAoS through the KAoS 
Grid service. All policies applicable to these entities will be distributed to 
the Guard associated with the KAoS Grid Service. 

4.3 Expressing Policies 

The basic components of any authorization policy are the actor, action 
and target. A sample policy would read as follows: 

• It is permitted for actor(s) X to perform action(s) Y on target(s) Z. 

Actors requesting to execute an action are mapped to various actor 
classes and instances in KPO. In our Whiteboard example, the actor would 
be the client acting on behalf of the user who is identified by their X.509 
certificate. Registration adds each client to the existing KAoS ontology, 
enabling policies to be written about the client or its domain. 

The actions can be represented at different levels of generality. A policy 
defined on a more general action might permit or forbid overall access to a 
service, which is useful for simple services or services that do not provide 
varying levels of access. For example, a policy defining overall permissions 
for a whiteboard service might make use of generic communication concepts 
in the existing KPO as in the following: 




KAoS Semantic Policy and Domain Services 



131 



• It is forbidden for Client X to perform a communication action 
if the action has a destination of Whiteboard Service Y. 

This policy would be used to prevent Client X from using Whiteboard 
Service Y. KAoS already understands the concepts of “forbidden”, 
“communication action” and “has destination.” KAoS will also understand 
“Client X” and “Whiteboard Service Y” once each entity registers. 

More complex services may require new concepts in the ontology that 
map to specific actions on a Grid Service. In this case, the ontology can be 
extended as in Figure 6.4 for the Whiteboard Service. The more detailed the 
ontology, the finer the level of control KAoS can provide for the service. 
For example, using the ontology from Figure 6.4 and the domain structure 
from Figure 6.3 it is now possible to write a policy restricting only the 
“KAoS-Team-Members” from performing “EncryptedWriteAction” to the 
specific Whiteboard service. 

Extended ontologies for the specific domain space and loaded into KAoS 
using a utility provided by KAoS. We are currently working on a tool to 
automatically generate a DAML ontology for a given WSDL specification. 
This resulting ontology would not be generic, but could be modified to refer 
to a generic ontology. We also have begun work on extensions to KPAT to 
allow ontologies to be extended through easy-to-use graphical tools. 

Targets can be clients, services, or domain specific entities. The first two 
cases are added to the KAoS ontology upon registration, but the last case 
requires manual ontology development similar to that described for actions. 
For a more detailed discussion on the specifics of KAoS policies the reader 
is directed to [8, 32]. 

Policies may be written to restrict a client’s use of a resource, or to 
restrict the set of access rights delegated to the KAoS Grid service. 
Conflicting policies can be identified and, if desired, harmonized through the 
use of an online theorem prover integrated with KAoS [32]. 

4.4 Checking Authorization 

Since the KAoS Grid Service has full control of access to a given 
resource based on the rights permitted by participating resources, it serves as 
the enforcer, using Globus local enforcement mechanisms. The KAoS Grid 
service coordinates with the Guard to determine authorization for a 
requested action. Once registered, clients will have access to the Grid service 
based on the policies in KAoS. As policies are added into KAoS through 
KPAT, they are forwarded to the Guard associated with the KAoS Grid 
service. In our Whiteboard example, a Whiteboard client would set a 
“KAoS” property in their environment to indicate their desire to use KAoS 
services. In the future, this information could be obtained from the service 
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lookup. Once the “KAoS” property is set, the request handlers do all the 
work. The request handler contacts the KAoS Grid service with the request. 
The KAoS Grid service will check if the requested action is authorized based 
on current policies by querying the Guard. If the Guard allows the requested 
action, KAoS Grid service initializes a restricted proxy certificate by putting 
the permissions needed to execute the action in its own end entity certificate. 
This certificate is the one provided by the resource at registration and maps 
to the local control mechanism. KAoS Grid service also sets the proxy 
lifetime and signs it. The restricted proxy certificate is returned to the client. 
The client then uses this proxy certificate to access the service. The entire 
process is illustrated in Figure 6.6. 

When a service receives a request it checks the submitted certificate 
against the local control mechanisms. Services can also check permissions 
by querying the KAoS Grid service. The service checks to ensure that action 
requested is covered by the intersection of the rights given to the KAoS 
service and the rights embedded in the certificate by the KAoS service. This 
allows the local resource owner to write policies restricting the rights it 
allows KAoS to delegate. 



5. RELATED WORK 

Several efforts are underway to improve security within Grid Services 
and Web Services environments. 

5.1 Web Service Approaches 

One of the reasons we focused on OGSA as our first foray into 
integrating KAoS with Web Services is that no general Web Services 
approach to security equivalent to that in OGSA has yet been defined. In 
Web Services environments, an approach for SOAP-based message security 
[2] has been developed. The goal of this effort is complementary to what is 
described in this paper, providing for the basic needs of message integrity, 
confidentiality, and single-message authentication. XACML [23] is another 
approach to Web Services security that provides a core schema and 
corresponding namespace for the expression of access control policies. The 
use of XML as a standard for policy expression has both advantages and 
disadvantages. The major advantage of using XML is its straightforward 
extensibility (a feature shared with Semantic Web languages such as RDF, 
DAML, and OWL, which are built using XML as a foundation). The 
problem with mere XML is that its semantics are mostly implicit. Meaning 
is conveyed based on a shared understanding derived from human 
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consensus. The disadvantage of implicit semantics is that they are rife with 
ambiguity, promote fragmentation into incompatible representation 
variations, and require extra manual work that could be saved by a richer 
representation (see the Semantic Integration chapter of [4]). The DAML- 
based policy representation approach in this paper, however, could be 
mapped to lower level XACML representations if required by an 
implementation — mapping from more expressive to less expressive 
representations is relatively straightforward. 

SAML [24] is an XML-based specification for exchanging security 
authentication and authorization information. A Web service uses SAML to 
gather the authentication information and the attributes available to the 
client, and then sends the gathered evidence to the Policy Decision Point 
(PDP). PDP returns the authorization decision, which is enforced at Policy 
Enforcement Point. SAML and XACML are designed to be complementary, 
since XACML can be used as the back-end language for PDP to talk to 
policy stores. 

Since SAML does not place any restriction on the underlying certificate 
processing, it can provide a generic description for either GSI or any other 
security mechanism. However, the SAML model puts too much burden on 
the services by requiring them to gather the evidence needed for policy 
decision. Moreover, SAML also suffers from the same problem as XACML 
when used to express attributes and other assertions. 

5.2 Globus Community Authorization Service 

The Globus Project identified a key problem associated with the 
formation and operation of distributed virtual communities: how to specify 
and enforce community policies [25]. Some of the policy challenges in the 
Grid Computing environment are scalability, flexibility, expressiveness, and 
policy hierarchy [25]. The Globus solution was to enhance the GSI with a 
Community Authorization Service (CAS). CAS provides an intermediate 
layer that removes the requirement of a trust relationship between specific 
clients and services. Instead services establish a trust with CAS server and 
clients coordinate a trust with a CAS server, but neither requires a direct 
trust relationship. 

CAS is responsible for managing the policies that govern access to a 
community’s resource. It allows resource owners to grant access to blocks of 
resources to a community as a whole, and let the community itself manage 
fine-grained control. In order to gain access to a CAS-managed community 
resource, a user must first acquire a capability, defined by a CAS-maintained 
community policy database, from the CAS Server. The CAS capability is 
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used to authenticate the user to the resource, by checking the capability 
against local policy information [25]. 

Although the Globus Project acknowledges the need for advanced policy 
languages, the goal of CAS was not to develop a policy language, so it uses 
a simple approach based on a list of rights. They did provide APIs to allow 
pluggable modules for acquiring, parsing, and evaluation of policy [25]. 

5.3 Comparison of CAS and KAoS 

The addition of CAS has moved the Globus project in a direction 
consistent to the services already provided by KAoS. The Globus idea of 
community is very similar to the KAoS idea of a domain, though KAoS 
domains allow a greater degree of flexibility, domain complexity, and 
dynamicity. Domains and communities increase scalability and simplify 
policy administration. Both KAoS and CAS provide a method for policy 
creation, although KAoS provides a much more sophisticated approach. 
Both rely on local enforcement based on Globus GSI. 

A major difference between CAS and KAoS is that authorization support 
for CAS is only present in GT 2.0. KAoS has been designed to work only 
with the OGSA-compliant GT 3.0a. Another significant difference is that 
KAoS uses DAML as a policy representation and provides advanced 
specification and analytic tools that have been defined to work with it. The 
use of DAML and the Java Theorem Prover (JTP) provides a highly capable 
and extensible policy representation (as described in Section 3). 
Additionally, KAoS Grid service provides a bridge to the world of software 
agents by establishing a flexible security infrastructure where agents are 
dynamically granted needed rights based on domain information and 
policies. Exploiting the synergy between Grid Services and software agents 
provides great potential. This potential is even greater with the 
understanding that software agents’ behavior and their interaction with Grid 
services can be controlled through high level policy management. 

One concern of both Globus and KAoS is that there is no mechanism for 
proxy certificate revocation. Globus relies on short lifetimes to limit proxy 
credentials. An updated policy in KAoS would not take effect until the 
current proxy credential expired, forcing the user to return to KAoS for an 
update. 

5.4 Other Approaches to Policies 

Some alternative approaches to represent and reason about policies for 
multi-agent and distributed systems include Rei [18] and Ponder [9]. 
Although Rei does employ a powerful policy language based on deontic 
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logic, it lacks any support in policy enforcement and requires extra effort by 
developers to integrate it into existing platforms such as the Globus Toolkit. 
The policy actions of Ponder, on the other hand, can be directly implemented 
in Java with little additional effort, and has resulted in its use in practical 
applications. However, Ponder’s inability to change policies at runtime and 
its low level of abstraction of policies raise doubts about its ability to meet 
the requirements of a dynamic environment typical of multi-agent systems. 
For further comparison of Rei and Ponder and KAoS, the reader is directed 
to [29]. 



6. CONCLUSIONS AND FUTURE WORK 

Developing ways to manage distributed resources has become an 
increasingly critical issue as the world moves toward an internet scaled use 
of these resources. Both multi-agent systems and Grid Computing 
technologies have demonstrated usefulness in various areas of computing. 
Each has also demonstrated the need for effective management techniques. 
KAoS Domain and Policy services have proven to be an effective tool in 
both instances. This presents opportunities to those wishing to mix agent and 
non-agent implementations indiscriminately. We believe this synergy is 
beneficial to the agent, Web Services, and Grid Computing communities. 

Our work in this area has also provided valuable insight into ways of 
extending KAoS to other areas. General, non-GSI-enabled, Web Services is 
the next logical step, and we are monitoring the progress mentioned in the 
Related Work section to exploit opportunities as they present themselves. A 
depiction of the Web Service areas we are discussing is shown in Figure 6.7. 
Based on GSI provided by GT3, our implementation of the KAoS Grid 
service is flexible enough to govern a broad class of services that use GSI as 
the security mechanism, but in order to provide full control for OGSA core 
functionalities (e.g. service creation, service data query, etc) that are required 
for Grid services, more work on developing a well-designed ontology 
appropriate for these core functionalities is necessary. 
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Web services 




Figure 6.7 Relationship between GS1 and Grid services 

Our current implementation also has room for improvement in certain 
areas. For example, domain membership is established by explicit 
registration of components, but in the future the domain could be assigned 
by a manager, determined by policy, or established based on the information 
in the component’s credential. Also, we are currently working on a tool to 
automatically generate a DAML ontology for a given WSDL specification. 
This resulting ontology would not be generic, but could be modified to refer 
to a generic ontology. We also have begun work on extensions to KPAT to 
allow ontologies to be extended through easy-to-use graphical tools. We feel 
there is much potential in this area. 
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Abstract The complexity of Web services and software agents engineering calls for an 
approach that aims first, at hiding this complexity and second, at supporting 
designers in their design and development work. This chapter presents such an 
approach, which proposes three aspects related to Web services and software 
agents engineering: intrinsic , organizational/functional, and behavioral. Once 
the Web services and software agents are engineered, the user in collaboration, 
with some of the software agents, composes Web services into composite services. 
The selection of Web services to participate in a composite service is based on two 
criteria: the execution cost of a Web service and the location of the computing 
hosts on which the Web service is performed. 



1. INTRODUCTION 

With the latest development of information technologies, businesses are 
adopting Web-based applications for more worldwide visibility and efficient 
business processes. Web services are among the technologies that help these 
businesses in reaching these objectives. A Web service is an accessible applica- 
tion that other applications and humans can discover and trigger (16). Various 
standards are behind the widespread adoption of Web services, including WSDL 
(Web Services Description Language), UDDI (Universal Description, Discov- 
ery, and Integration), and SOAP (Simple Object Access Protocol) (6). One of 
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the strengths of Web services is their capacity to be composed into high-level 
business processes known as composite services. 

The growing interest in mobile and wireless technologies is nowadays wit- 
nessed by a new generation of Web services, which are proposed for use by 
those who are frequently on the move (e.g., sales representatives). These per- 
sons rely on mobile devices such as cell-phones to conduct their day-to-day 
operations. M-services (M for mobile) denote this type of Web services and 
are intended to be either (i) triggered remotely from mobile devices for execu- 
tion purposes, or (ii) wirelessly transferred from provider sites to users’ mobile 
devices on which their execution is carried out (11). 

Composing services (Web services or M-services) rather than accessing a 
single service is essential and provides much better benefits to users. Composi- 
tion primarily addresses the situation of a user’s request that cannot be satisfied 
by any available service, whereas a composite service obtained by combining 
available services might be used (4). Searching for the relevant component 
services, integrating the selected component services into a composite service, 
triggering these component services, and monitoring their execution are among 
the operations that users will be responsible for. Due to the complexity associ- 
ated with most of these operations, it is deemed appropriate to consider using 
software agents to assist users in their work (8). 

Composition of services is a very active area of research and development (2, 
14). However, very little has been accomplished so far regarding providing the 
appropriate support through approaches to those who will be responsible for 
specifying the engineering operations of Web services and software agents. 
In this chapter, we present such an approach that consists of three aspects, 
denoted by intrinsic , organizational/ functional, and behavioral. Each aspect 
of the approach focusses on specific elements of the component (i.e., agent or 
service) that is intended to be specified: 

■ Agent: the intrinsic aspect describes an agent as an independent entity. 
The organizational aspect describes an agent as a member of a commu- 
nity. Finally, the behavioral aspect describes the reactions of an agent to 
the interactions in which it takes part. 

■ Service: the intrinsic aspect describes a service as an independent entity. 
The functional aspect describes a service when it is a member of a com- 
posite service. Finally, the behavioral aspect describes the states that a 
service takes when agents trigger the service. 

The rest of this chapter is organized as follows. Section 2 overviews the 
concepts of Web service and M-service. Section 3 introduces the specification 
approach and the aspects it encompasses. A running example, which illustrates 
the use of the specification approach, is also provided in this section. Sec- 
tion 4 explains the process of agentifying the composition of services. The 
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implementation of this environment is outlined in Section 5. Finally, Section 6 
concludes the chapter. 



2. BACKGROUND 

In this chapter, C-service denotes a composite service and P-service denotes 
a primitive service, which is either a Web service or an M-service. 

2.1 Services 

In (3), a Web service is an accessible application that other applications and 
humans can discover and trigger to satisfy various needs such as hotel book- 
ing. Benatallah et al. associate the following properties with a Web service: 
(i) independent as much as possible from specific platforms and computing 
paradigms; (ii) developed particularly for inter-organizational situations; and 
(iii) easily composable so that its composition with other Web services does 
not require the development of complex adapters. 

In (11), two definitions are proposed for an M-service. The weak definition 
is to remotely trigger a Web service from a mobile device for execution. In that 
case the Web service acts as an M-service. The strong definition is to transfer a 
Web service from its hosting site to a mobile device where its processing occurs. 
In that case the Web service acts as an M-service that presents the following 
properties: (i) transportable through wireless networks; (ii) composable with 
other M-services; (iii) adaptable according to the computing features of mobile 
devices; and (iv) runnable on mobile devices. 

In this chapter, the following assumptions are made. The P-services that 
constitute a C-service are only of type Web service (i.e., no P-services of type 
mobile are allowed to take part in a composite service). In addition, a C-service 
is offered to users for invocation purposes in two different types: Web type for 
stationary users and mobile type (that complies with the weak definition of 
an M-service) for mobile users. For the needs of specifying the component 
services of a composite service, service chart diagrams are used. 

2.2 Service Chart Diagrams 

In (9), the concept of service chart diagram was introduced as a means 
for specifying the component services of a composite service. A service chart 
diagram leverages a state chart diagram (7), since the emphasis is on the context 
surrounding the execution of a service rather than only on the states of the 



service. 
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A service chart diagram represents a service from five perspectives, each 
perspective has a set of properties (Figure 7.1). The state perspective corre- 
sponds to the states of the service (i.e., a traditional state chart). Th q flow 
perspective corresponds to the execution chronology of the composite service 
in which the service participates (Previous services/Next services properties). 
The business perspective identifies the organizations that provide the service 
(Business property). The information perspective identifies the data that are 
exchanged between the services of the composite service (Data from previous 
services/Data for next services properties). Finally, the performance perspec- 
tive illustrates the ways the service is invoked for execution whether remotely 
or locally (Performance type property, (10)). 



Service 




Figure 7.1. Service chart diagram of a primitive service 



Since a composite service is made of up of several component services 
(primitive or composite), the process model underlying the composite service 
is specified as a UML state chart diagram (the value added by such a diagram 
to service composition is discussed in (1)). In this diagram, states are asso- 
ciated with the service chart diagrams of the component primitive-services, 
and transitions are labelled with events, conditions, and variable assignment 
operations (Figure 7.2). 



3. THE THREE-ASPECT SPECIFICATION 
APPROACH 

In this section, we motivate the role of the three-aspect specification approach 
and then discuss its concepts and use with a running scenario. 
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Composite Service 




Figure 7.2. State chart diagram of a composite service 



3.1 Motivation 

It is largely accepted that needs and requirements of users are becoming di- 
verse and complex. To satisfy some of these needs and requirements, advanced 
components are required so that new types of application can be developed. 
Software agents, Web services, and M-services are samples of the advanced 
components that can be considered in this development. 

Software agents are autonomous entities that take initiative in solving prob- 
lems, and services are computing packages that are intended to be composed 
and executed. This composition is featured by multiple operations such as look- 
ing for the relevant services, integrating the services into a composite service, 
triggering the services at the right time and in the right order, and monitoring 
the execution progress of the composite service for exception handling. All 
these operations can be outsourced to software agents because of their multiple 
capacities. For instance, a software agent is autonomous. Thus, it can make 
decisions on the user’s behalf. Second, a software agent can be mobile. Thus, 
it can move from one host to another so that it locally triggers the services of 
the host. Third, a software agent is collaborative. Thus, it can work with other 
agents that identify for example the providers of services. Last but not least, 
a software agent is reactive. Thus, it can monitor the events that occur in the 
user’s environment so that relevant actions are taken. 
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Having services and software agents in the same environment sheds light 
on the appropriateness of a specification approach. This approach supports 
defining which software agents do what, and when, how, and where these agents 
are supposed to act. In the first step, the specification approach is applied to 
agents and services taken independently from each other. In the second step, 
the specification approach is applied to agents and services taken in a combined 
way. 



3.2 The Three Aspects 

The specification approach includes three aspects known as intrinsic , orga- 
nizational/functional, and behavioral. In the following, the properties of each 
aspect are described and then, applied to a running example. It should be noted 
that while the values of certain properties are obtained during design-time, 
other properties’ values are obtained during run-time. These values can be of 
different types (text, number, etc.). 

Software Agent Table 7.1 lists the properties per aspect of the specification 
approach when applied to software agents. 



Table 7.1. Specification approach applied to software agents 



Aspect 


Properties 


Values obtained 


Intrinsic 


identifier, role, type 


design-time 


Organizational 


visited domain, not-visited domain 


run-time 


Behavioral 


state chart diagram 


design-time 



1 The intrinsic aspect has three properties: identifier (identifies an agent 
with regard to a certain computing platform, which is part of an Inter- 
net domain), role (describes the responsibilities of an agent), and type 
(indicates if an agent is of type provider or user). 

2 The organizational aspect is built upon the notion of domain and consists 
of two properties: visited domain , and not-visited domain. If a service 
is locally triggered (Performance perspective of Figure 7.1), this means 
that the requesting agent (which has to be mobile) is visiting the domain 
of the requested agent that manages the service. The location of this 
domain updates the visited- domain property. The opposite occurs if a 
service is remotely requested; the not-visited-domain property is updated. 
Section 4 discusses how services are associated with software agents. 
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3 The behavioral aspect has one property: state chart diagram (lists the 
states that an agent takes when it functions). 

Service Table 7.2 lists the properties per aspect of the specification approach 
when applied to services. 

Table 7.2. Specification approach applied to services 



Aspect 


Properties 


Values obtained 


Intrinsic 


identifier, description, type, input arguments, 
output arguments, cost 


design-time 


Functional 


component link, mandatory causal link, optional 
causal link 


design-time 


Behavioral 


state chart diagram 


design-time 



1 The intrinsic aspect consists of six properties: identifier (identifies a 
service with regard to what is offered to users), description (provides an 
overview on a service), type (indicates if a service is of type composite or 
primitive ), input arguments (lists the number and type of arguments that 
are submitted when a service is triggered), output arguments (lists the 
number and type of arguments that a service returns after processing), 
and cost (corresponds to the charges of executing a service). 

2 The functional aspect consists of three properties: component link (only 
applies to composite services and identifies the component primitive- 
services), mandatory causal link (identifies the primitive services that 
are attached to a primitive service; these primitive services must be 
added to a composite service in case this primitive service participates 
in the composite service), and optional causal link (identifies the com- 
ponent primitive-services that are attached to a primitive service; these 
services can be added to a composite service in case this primitive service 
participates in the composite service 1 ). 

3 The behavioral aspect has one property: state chart diagram (lists the 
states that a service takes when an agent triggers the service). 

Connection between Agents and Services 

1 Between intrinsic aspects. An agent of type provider has to know the 
services for which it is responsible. Thus, a service property is added to 
the intrinsic aspect of the agent (Table 7.1). 

2 Between organizational-functional aspects. To satisfy his needs, a user 
triggers a composite service, which will be assigned to an agent of type 
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user. This agent is aware of the component primitive-services that con- 
stitute the composite service using the properties that are associated with 
the functional aspect of the composite service. The agent of type user has 
to select the primitive services according to the execution cost criterion. 
In addition, the agent of type user has two options to trigger a primitive 
service: (i) locally within the same domain of the agent of type provider 
that manages the primitive service, or (ii) remotely from a different do- 
main of the agent of type provider that manages the primitive service. 
The type of invocation, whether remotely or locally, enables updating 
visited domain and not-visited domain properties of the organizational 
aspect of the agent of type user. 

3 Between behavioral aspects. When an agent interacts with its peers, it 
takes different states based on the messages it submits and receives. It 
may occur that agents initiate services during their interactions, which 
makes the services take specific states. 

3.3 Illustration Examples 

After presenting the three aspects of the specification approach, the current 
step consists of applying them to a fictional scenario denoted by vacation sum- 
mer. Four services are required to handle this scenario: flight reservation, hotel 
booking, attraction search, and user notification. The specification of agents 
according to the elements of Table 7.1 takes place once the agentification of 
services is completed (Table 7.4). 

Initially the designer specifies the component services according to the ele- 
ments of Table 7.2. Table 7.3 is an example of specifying the flight-reservation 
service. 

Once all the component services are specified, the designer starts working 
on the definition of the composite service for summer vacation. We recall that 
the designer has to define a state chart diagram for the composite service (Fig- 
ure 7.2). In this diagram, each state corresponds to the service chart diagram 
of a component service. The designer relies on the following details while 
working on the definition of summer- vacation composite-service: 

1 The P-services that constitute the vacation C-service are: flight reser- 
vation, hotel booking, attraction search, and user notification. These 
P-services are listed in component link property of the functional aspect 
of summer-vacation composite-service. 

2 Based on mandatory causal link property of the functional aspect of 
attraction search P-service, driving time calculation and car rental P- 
services have to be added to vacation C-service (Figure 7.3 (a)). The 
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Table 7.3. Specification of flight-reservation service 



Aspect 


Properties 


Values 


Intrinsic 


identifier 


idi 




description 


book a seat 




type 


primitive 




input arguments 


date of dep. /return, city 




output arguments 


confirmation yes/no 




cost 


5 (currency) 


Functional 


component link 


null 




mandatory causal link 


null 




optional causal link 


null 


Behavioral 


state diagram 


Figure 7.3 



first P-service checks the distance between the location of the hotel and 
the location of the main attraction. If the distance is greater than a user- 
defined value, the car rental P-service is triggered. 

3 Based on the optional causal link property of the functional aspect of the 
user notification P-service, the historic details P-service can be added 
to vacation C-service (Figure 7.3 (b)). This P-service provides historic 
information about the city that the user plans visiting. This new P-service 
is triggered upon user’s approval. 

Figure 7.3 is the state chart diagram of vacation-scenario composite-service. 
For the sake of brevity, only Flight reservation P-service is refined (Table 7.3). 
It is the first P-service to be triggered and is followed by hotel booking and 
attraction search P-services. Both need departure date, return date, and city 
of destination as inputs to be obtained from flight reservation P-service. This 
P-service takes two states: stand by and execution. The businesses that provide 
flight reservation P-service and its invocation method are identified during run- 
time (Section 4.3). 



4 . AGENTIFICATION OF SERVICE COMPOSITION 

In this section, we outline the agentification process of service composition. 
This agentification aims, primarily, at identifying the relevant types of software 
agent, which will be responsible for deploying the specification of a composite 
service (Figure 7.3). 
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Summer-vacation C-service 




Flight reservation P-service 



Figure 7.3. Representation of vacation- scenario composite-service 



4.1 Architecture 

Figure 7.4 illustrates a multi-domain architecture , which is the result of 
agentifying the composition of services. Domains are spread across the network 
and administrators maintain them. Two types of domain exist: user-domain 
and provider-domain. The existence of one user-domain 2 and several provider- 
domains is assumed. A domain is a computing platform on which services and 
agents are installed. Users browse the list of composite services from different 
types of device (fixed or mobile). 

The user-domain has a service-zone and a working-zone. The service-zone 
has a list of composite services that are specified using the approach of Section 3. 
The list announces composite services in two versions: Web version to users 
of fixed devices and mobile version to users of mobile devices. In addition, 
the service-zone has a bank from which user-agents are created. For their 
installation, user-agents are located in the working-zone of the user-domain. 
Enhanced with mobility mechanisms, user-agents may migrate to domains 
based on the strategy they will adopt for invoking the component services of a 
composite service (Section 4.3). A user-agent is associated with each composite 
service that the user selects. We recall that only primitive services of type Web 
participate in composite services. 

A provider-domain consists of a working-zone and several lists of prim- 
itive Web services. Each list corresponds to a specific application domain 
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Figure 7.4 . Software agent-based multi-domain architecture 
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(e.g., academia, travel). A working-zone receives user-agents arriving from 
the user-domain or from other provider-domains. Within provider-domains, 
installation and security procedures of user-agents are performed (these proce- 
dures are outside this chapter’s scope). Provider-agents handle the invocation 
requests that user-agents submit to component primitive-services. A user-agent 
submits a local request to a provider-agent in case both are in the same provider- 
domain. This means that the user-agent has moved to this provider-domain. 
The user-agent arrives from either the user-domain or a different provider- 
domain. In case the user-agent and provider-agent are in separate domains, 
the user-agent submits a remote request to the provider-agent so that the prim- 
itive service can be triggered. Table 7.4 specifies a user-agent according to the 
elements of Table 7.1. 

Table 7.4. Specification of an user-agent 



Aspect 


Properties 


Values 


Intrinsic 


identifier 


id3 




role 


satisfies user's needs 




type 


user 




service 


null 


Organizational 


visited domain 


null 




not-visited domain 


null 


Behavioral 


state diagram 


state-diagram2 



4.2 Operation 

The operation of the multi-domain architecture consists of the specification 
of the composite services and their deployment once users invoke them. The 
specification of a composite service was discussed in Section 3. The focus here 
is on the deployment of the specification of a composite service in terms of 
(i) selecting the component primitive-services because providers offer similar 
services, and (ii) executing the selected primitive-component services accord- 
ing to remote or local invocation type. Users browse the list of composite 
services from fixed or mobile devices. It should be noted that the type of 
device does not affect the deployment of a composite service. The only differ- 
ence concerns the communication protocol (HTTP vs. WAP), which supports 
the connection of users to the list of composite services. 

When a composite service is selected, the user submits details on his needs 
(e.g., city of destination, number of persons). This submission triggers the 
creation of a user-agent that handles the user’s request. Initially, the user-agent 
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is in the working zone of the user-domain. Afterwards, the user-agent starts 
the identification of the component primitive-services of the composite service. 
The user-agent uses component link property of the functional aspect. At this 
stage, the user-agent is aware of the appropriate primitive services. Before 
it interacts with the provider-agents of these primitive services, the user-agent 
checks if additional primitive services are not needed, too. For this purpose, the 
user-agent uses the mandatory causal link and optional causal link properties. 
The primitive services that are identified in the mandatory causal link property 
have to be attached to the composite service. Regarding the optional causal 
link property, the user-agent may decide to provide additional details that were 
not mentioned in the user’s initial request. 

Once the user-agent identifies the primitive services that “have to be” and 
“can be” attached to the composite service, it starts implementing the spec- 
ification of the composite service by interacting with the provider-agents of 
the primitive services. The user-agent may migrate to a provider-domain in 
which it locally requests the execution of a primitive service. Alternatively, the 
user-agent remotely requests the execution of a primitive service from the do- 
main (either a user-domain or a different provider-domain) in which it currently 
resides. Once all the primitive services are executed, the user-agent returns de- 
tails to the user. For the primitive services that were included according to 
optional causal link property, the user-agent seeks the user’s approval before 
invoking these primitive services. 



4.3 Primitive Services Selection and Execution 

For a composite service, the selection of its component primitive-services 
depends on two criteria: execution cost and location of computing hosts (a 
computing host corresponds to a provider- agent). Execution cost criterion is 
related to a primitive service (Table 7.2), whereas location of computing hosts 
criterion aims at gathering in the same provider-domain the maximum number 
of primitive services for execution, promoting local interactions over remote 
interactions. 

The use of the location of computing hosts criterion aims at reducing (i) the 
number of remote interactions between domains, (ii) the number of migrations 
of user-agents to domains, and (iii) the number of remote data exchanges be- 
tween domains. The identification of the relevant domains and their respective 
computing hosts is based on the following. First, the domain of where a service 
is currently being executed is considered (set A , Fig. 7.5). By selecting this do- 
main, remote data exchanges between services are avoided. Next, the domain 
of where the user-agent currently resides is considered (set B , Fig. 7.5). By 
selecting this domain, local invocations of services and local data exchanges be- 




152 



tween services are enabled. In case none of the aforementioned cases happens, 
any domain is considered (set C, Fig. 7.5). 

Definitions. For a user-agent, the deployment of the specification of a com- 
posite service consists of (i) associating each primitive service with a provider- 
agent, and (ii) defining the strategy of invoking the primitive service. We as- 
sume a C-service CS of n P-services, CS = {< p.si,pro.agt\,type >,-•*,< 
p.s n ,pro.agt n ,type >} where for each < p.Si,pro.agti,type >(ie[i,n]) the 
P-service p.Si is provided by the provider- agent pro.agti and invoked according 
either to remote or local type. The number of provider-agents that contribute 
to the provisioning of a composite service is not necessarily equal to the num- 
ber of primitive services that are involved in the composite service — certain 
provider-agents may contribute with more that one P-service. 

The execution cost of a P-service as defined by a provider is decomposed 
into two parts ( cost parameter in Table 7.2): 

■ Remote Execution Cost of a P-service includes (i) the cost of establishing 
a communication link between the domain in which the user-agent is now 
located and the domain of the provider-agent of the P-service, plus (ii) the 
cost of performing the P-service, plus (iii) the cost of returning the results 
from the domain of the provider-agent to the domain of the user-agent. 



■ Local Execution Cost of a P-service includes (i) the cost of moving the 
user-agent from the domain in which it resides now to the domain of 
the provider-agent of the P-service, plus (ii) the cost of performing the 
P-service. 

Selection . The selection of the primitive services for composition is decom- 
posed into two phases. Phase 1 consists of searching for the provider-agents that 
have the P-services. Because provider-agents could have similar P-services, 
Phase 2 consists of selecting a particular provider-agent using execution cost 
and location of computing hosts criteria. 

In Phase 1, the identification of the provider-agents is based on the business 
perspective of a service chart diagram (Figure 7. 1). For each P-service p.s ^ , po- 
tential provider-agents are identified. This is similar to < p.s^ PRO. AGTi, type > 
where PRO. A GTi = {pro.agti, pro.a#t m } is the list of provider-agents 

that have the P-service p.s^ in common. 

In Phase 2, because provider-agents might have P-services in common, the 
association of a P-service with a specific provider-agent has to be completed. 

In addition, because of the location criterion the P-services are treated one at 
a time. The definition of < p.s%, pro.agti, type > is broken down into two 
sub-phases. 
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In Phase 2.1, the P-service p.s { ( i=1 ) of CS is considered. In this phase, 
only execution cost criterion is considered (location criterion does not hold; 
a primitive service is, in this phase, taken independently from its predecessor 
primitive service). From each provider-agent of PROAGT i ( i=rl ) that offers the 
P-service p.si (^i), the user-agent receives the execution cost for remote and 
local invocation types (Equation 7.1). 

pro.agti : (remote, local). Cost(p.s\) 

User — agent: p.s i j (7.1) 

, pro.agtk : (remote, local). Cost(p.$f) 

Based on the offers that provider-agents submit to the user-agent, this se- 
lects the minimum cost per offer between the two types of invocation. Af- 
terwards, the user- agent selects for the P-service p.Si ( i=1 ) the minimum cost 
among all the costs that it has selected. For instance, the user-agent sets 

< p.s\,pro.agt 2 1 remote >: pro.agt 2 provides p.s\ and p.s\ is remotely in- 
voked. Because of the remote invocation, the user-agent and pro.agt 2 will be 
in two different domains. 

In Phase 2.2, the user- agent continues its selection work on the remaining 
P-services 80 one at a time. Now, the two selection criteria 

are simultaneously considered. We recall that the location criterion is privi- 
leged over the execution cost criterion because of the benefits we cited earlier. 
Considering the location criterion, the provider-agent that is associated with a 
P-service p.s i (ie[2,n]) depends on the provider-agent that is chosen to offer the 
predecessor P-service p.s^i . The user-agent adopts the algorithm of Figure 7.5 
in order to identify the provider-agents with whom it will interact about their 
primitive services (in the algorithm, < p.Si-i, pro. agU-i,local\r emote > 
is assumed). When the user-agent finishes working on a P-service p.su the 
provider-agent and invocation strategy of that P-service are known. The pur- 
pose of the algorithm is to generate a short list of provider-agents with whom 
the user-agent will have to interact about their services. This short list ranks the 
domains in which the provider-agents and user-agent currently reside (A, B , 
and C sets, lines 08-12). 

Execution . When all the primitive services of a composite service are known, 
the user-agent invokes them through their respective provider-agents. The fol- 
lowing C-service CS = {< p.s\, pro.agti, local >,< p.S 2 ,pro.agt 2 , local >, 

< p>S 3 , pro. agt%, remote >} is used. Initially, the user-agent is in the user- 
domain, pro.agti and pro.agt 2 are in provider-domain i, and pro.agt 3 is in 
provider- domain 3 . Since p.s\ is going to be locally executed, the user-agent 
migrates from the user-domain to provider-domain\. Once the execution of 
p.s\ is completed, the user- agent triggers locally p .$2 . Because pro.agt 2 and 
pro.agti are in the same domain, this shows how the location criterion is used. 
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for each < p.s*, PRO. AGTi, type >,i = 2, • ♦ • ,p 
begin 

I A <— (j) //provider-agents in the same domain as pro.agti-i 
I B <f> //provider-agents in the same domain as user-agent 
I C *— <j> //provider-agents that are in other domains 
I for (j - 1; j <= \\PRO.AGTi\\;j + +) llpro.agtj € PRO.AGTi 
I begin 

I I if domain (pro. agtj) = domain (pro.agU^O 
I | then A <— A U pro. agtj 

I I else if domain (pro.agtj) = domain (user — agent ) 

I I then B <— B U pro.agtj 

I I else C * — C U pro.agtj 

I end //AUBUC = PRO.AGT, 

I if A ^ (f) 

I then contact provider-agents of A - Go Phase 2.1 
I else if B ^ <p 

I then contact provider-agents of B - Go Phase 2.1 

i else contact provider-agents of C - Go Phase 2.1 

end 



Figure 7.5. Algorithm for provider-agents selection 

Moreover, this shows that the transfer of data from p.s\ to p.s 2 if both are in- 
terdependent is done locally, which avoids dealing with network-connection 
failures. Finally, from provider-domaini the user-agent submits a remote re- 
quest to pro.agtj so that p.s^ is triggered. The transfer of data from p.s 2 to p.ss 
if both are interdependent is remotely done, which stresses the importance of 
being aware of network-connection failures. 

4.4 Interleaving Selection and Execution 

It is shown in Section 4.3 that the current deployment of a composite ser- 
vice is sequential and requires that the user-agent takes the following steps in 
turn: (i) process all the offers of provider-agents about the primitive services, 
(ii) construct the composite service, and finally (iii) execute the composite ser- 
vice. It would be preferable if the selection and execution of services could be 
interleaved (13). The user-agent has to delegate a part of its duties (either selec- 
tion or execution) to what we refer to as delegate-agent in the following. Both 
user-agent and delegate-agent are created at the same time (Section 4.2). While 
the user-agent is remotely interacting with provider-agents or visiting domains 
of provider-agents, the delegate-agent is preparing the component services for 
execution on behalf of the user-agent, and submitting the details about what 
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the user-agent has to carry out. These details concern the provider-agents of 
the component services and the respective invocation types of these component 
services. While the delegate-agent is working on the P-service p.s u the user- 
agent is executing the P-service p.Si-\. Therefore, the delegate-agent is always 
one-step ahead of the user-agent. User-agent and delegate-agent communicate 
in two ways: locally when both agents are in the user-domain and remotely 
when the delegate-agent is in the user-domain and the user-agent is in one of 
the provider-domains visiting their provider-agents. 



User-domain 




Figure 7.6. Interleaving service selection and execution 



Figure 7.6 explains how user-agent and delegate-agent implement service 
selection and execution interleaving. We assume a C-service CS = {< 
p.si, Ipro.agt, Itype >, < p.$ 2 , ‘Ipro.agt, ?type >}. First of all, thedelegate- 
agent starts working on p.s\. Based on the offers of provider-agents, the 
delegate- agent defines for p.s i the following: local execution in provider- 
domairti of pro.agt\ (< p.si,pro.agti , local >). Therefore, the delegate-agent 
asks the user-agent to migrate to provider-domain \ . Before that, the user- agent 
was residing in the user-domain. While the user-agent is getting ready for mi- 
gration, the delegate-agent starts the preparation of p.S2- After performing all 
the necessary operations, the delegate-agent establishes for p.S2 the following: 
local execution in provider-domain 2 of pro.agt2 (< p.S2 ) pro.agt2^ > remote >). 
The details on p.S2 are transferred to the user- agent, which is now located in 
pmvider-domain\. After the user-agent completes the execution of p.s 1, it 
moves to provider- domain 2 so that it can locally interact with pro.agt2- 
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5. DISCUSSION ON IMPLEMENTATION 

We first overview the implementation elements of the prototype and then 
compares to other works one of the features of the prototype, which is in- 
tegrating location of computing hosts criterion into the strategy of selecting 
component services. 

The architecture of the prototype consists of a service composition environ- 
ment, a pool of services, and a pool of agents. All these components are being 
implemented in Java. Services communicate through XML documents. The 
service composition environment consists of a set of integrated tools that allow 
service providers and users to create and execute services. WSDL is used to 
specify Web services and UDDI is used as a service discovery. Since WSDL 
only focuses on how to invoke a Web service, some of the attributes of the 
three-aspect specification approach are not supported by WSDL (e.g., type of 
domain). To overcome this limitation, such attributes are specified as tModels. 




Figure 7. 7. Environment for Web services composition 



The Service Builder assists providers in defining new services and editing 
existing ones, as well. A service definition is edited through a visual interface 
(Figure 7.7), and translated into an XML document for further processing. 
The service builder offers an editor for describing a service chart diagram of 
a component service that participates in a composite service (an extension of 
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our previous work in (15)). In addition, the service builder provides means 
for describing the properties of states (e.g., state ID, state name, component 
service operation) and transitions (e.g., ECA rules), which both constitute the 
specification of a composite service (Figure 7.2). 

We highlighted throughout this chapter that the identification of the compo- 
nent services of a composite service is basically a selection process that relies 
on different criteria, including execution cost, execution time, reliability, and 
reputation of services (18). In this chapter, we considered the location of com- 
puting hosts as another selection criterion because of the advantages the use 
of this criterion provides. We recall that a computing host is a resource on 
which Web services are performed. Further, we considered a computing host 
as a member of a domain. By gathering services for execution in the same 
domain of computing hosts, the following advantages are obtained: (i) remote 
interactions between agents of different domains are reduced; (ii) extra migra- 
tions of agents to remote domains are avoided; and (iii) remote exchanges of 
data between domains are reduced. The motive of the location criterion is to 
privilege local interactions over remote interactions between the components 
of an environment of Web services. Local interactions are slightly affected by 
the reliability of the communication channels. In addition, local interactions 
ensure better security to the information exchanged. 

Several other projects on service composition exist (5, 12, 17). Chakraborty 
et al. have introduced a reactive service composition architecture for pervasive 
computing environments (5). The architecture consists of five layers, among 
them the service execution layer. This layer optimizes the bandwidth required 
to transfer data over wireless links in order to minimize the bandwidth-use 
during service execution. This optimization approach has similarities with 
our use of the location criterion that aims, for instance, at reducing the data 
exchanges between distant domains. Another relevant work to the location 
criterion is presented in (12). Since it will be challenging to create services that 
can execute well on the large variety of devices, Messer et al. suggest transpar- 
ently offloading portions of a service code from resource-constrained devices 
to nearby servers (12). Code-offloading requires partitioning strategies: If two 
components frequently interact (e.g., because of many method invocations), 
then a partitioning strategy should suggest placing these components together 
on one machine; splitting them across the network could severely affect perfor- 
mance. However, we noted that a repetitive selection of the same host might 
overload a machine. In this chapter, we showed that the overloading can be 
avoided for two main reasons. First, the location criterion is applied to domains 
of computing hosts rather than to individual computing hosts. Second, the lo- 
cation criterion finds and ranks domains of computing hosts using a specific 
algorithm (Figure 7.5). When an appropriate domain is identified, traditional 
selection criteria are applied to identify the best computing host. 
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6. CONCLUSION 

In this chapter, we presented an approach for specifying Web services and 
software agents. The approach suggests three aspects for modeling both com- 
ponents: intrinsic , organizational/functional , and behavioral. For illustration 
purposes, the specification approach’s aspects have been applied to a running 
scenario called summer vacation. 

To alleviate the complexity of composing services in terms of identifying 
who offers services, how to select services, and how to trigger services, the 
specification approach associates first both users and services with software 
agents, and second uses service chart diagrams and state chart diagrams. A 
service chart diagram represents a component service from five perspectives 
(state, flow, business, information, and performance), whereas a state chart 
diagram specifies the process model underlying a composite service. 

One of the features of agentifying service composition, which was described 
in this chapter, is a two-phase process. The first phase identifies the providers 
that offer the component services needed to constitute a composite service. 
Following that, the second phase selects specific providers according to two 
criteria: execution cost and location of computing hosts. Location criterion 
aims at gathering the maximum number of component services to be executed 
in the same domain of computing hosts so that local interactions can be enabled. 
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NOTES 

1. A person attending a conference in city X could be interested in visiting the famous places of that 
city even if the person did not explicitly mention his interest. 

2. The use of a single user-domain brings up the issues of bottleneck and single point-of-failure. We 
do not address those here, except to note that both could be handled with replication techniques. 
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Abstract Locating suitable services within a dynamic distributed system is a computa- 
tionally intensive process, with no guarantee of quality and suitability of the 
discovered services. This is especially true for transient services, i.e. services 
which are likely to exist over short time frames. A significant effort has already 
been spent on developing distributed registry systems - such as the UDDI registry 
in Web services - to enable services to be published, and subsequently discov- 
ered. Regardless of the type of registry being used, it is nevertheless important 
to categorise services based on their particular properties - a process that should 
also aid the subsequent discovery of the service. A mechanism for grouping ser- 
vices based on a particular set of properties is investigated here - leading to the 
formation of service communities. Each such community is based on the exis- 
tence of common parameter values being shared by members of the community. 
The structure of such a community is described, and a particular type of com- 
munity established on the basis of Quality of Service properties is subsequently 
developed. 



1. INTRODUCTION 

There has been an increase in interest recently within the Grid com- 
munity 1 towards “Service Oriented” Computing. Services are often seen as 
a natural progression from component based software development ([10]), 
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and as a means to integrate different component development frameworks. 
A service in this context may be defined as a behaviour that is provided by a 
component for use by any other component based on a network-addressable 
interface contract (generally identifying some capability provided by the ser- 
vice). A service interface stresses interoperability, and may be dynamically 
discovered and used. According to ([6]), the service abstraction may be 
used to specify access to computational resources, storage resources, and 
networks in a unified way. How the actual service is implemented is hidden 
from the user through the service interface. Hence, a compute service may 
be implemented on a single or multi-processor machine - however, these 
details may not be directly exposed in the service contract. The granularity 
of a service can vary - and a service can be hosted on a single machine, or it 
may be distributed. The ‘TeraGrid” project 2 provides an example of the use 
of services for managing access to computational and data resources. In this 
project, a computational cluster of Intel IA-64 machines may be viewed as 
a compute service, for instance - hiding details of the underlying operating 
system and network. A developer would interact with such a system using 
the Open Grid Services Architecture (OGSA) toolkit ([6]), derived from 
the Globus system 3 , and consisting of a collection of services and software 
libraries. 

A key aspect of many existing Grid computing applications is the dis- 
tributed sharing of services - often organised into a “Virtual Organisation" 
(VO) ([6]). Based on this idea, services from different providers may be dy- 
namically combined based on demand (although the location of a service is 
often pre-specified), to enable the composition of these services for solving 
a single large problem. Each service may be shared concurrently between a 
number of VOs. The discovery of suitable services plays a significant role 
in organising and managing such organisations. 

In cases where the location of services is not pre-defined, the notion of 
discovery becomes a critical and often time-consuming process. Service 
discovery imposes an overhead on network access, as the time to under- 
take discovery increases as the number of service providers/users (peers) 
increase. Grouping services and restricting interactions to be between a set 
of peers is a key factor to scale the resource discovery problem. Any initial 
cost used in categorising peers can provide benefits for discovering prefer- 
able peers without a large discovery cost subsequently - thereby leading to 
the development of “communities". A similar problem in Grid Computing 
is the “connection problem" ([4]), where peers need to find other suitable 
peers to co-operate with, assist, or interact with. The connection problem is 
essentially about locating suitable service providers who have the capabili- 
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ties necessary to solve the problem posed by a client. As the system within 
which this discovery request is sent is open, and may change dynamically, 
use of broadcast mechanisms can only be applied in limited contexts. 

“Focused Addressing" ([9]) is one solution to the connection problem 
where requests are sent to particular subset of peers, believed to assist the 
requesting peer. Such a subset may include matchmakers or brokers , which 
act as mediators between the service requestor and the providers. The 
key theme in focused addressing is to enable greater utilisation of service 
providers. 

Individual peers, although selfish, are expected to interact with each other 
in some way. If this was not the case, it would be impossible to establish 
VOs - or allow sharing of services between different applications. Co- 
operation of one form or another therefore becomes essential. Each peer 
prefers to be in an environment where it may be easily discovered by a 
suitable service user, and can locate other peers with minimum effort/cost. 
To assist discovery, peers providing services may be grouped together based 
on common attributes such as: type of service, resources owned, and domain 
of operation, for instance. We assume that each community has a manager 
entity or a “Service Peer" responsible for sustaining the community, and 
interacting with Service Peers in other communities. Such a hierarchy 
(whereby individual peers are not allowed to interact directly with peers 
in other communities), is also useful to restrict the number of messages 
exchanged between communities. 

Existing work in supporting service discovery using registry services, 
such as UDDI, differs from our work. Current work in Web Services does 
not specify how UDDI registries must interact with each other, or how they 
may be organised into a hierarchy. Although there have been some efforts 
toward the establishment of “Business Registries" - essentially involving 
a collection of UDDI registries, the exact interaction between such UDDI 
registries is not easy to enforce. There is no explicit policy on how inter- 
action between such registries is to be supported, or how their content is 
to replicated. Our focus on communities also allows the existence of reg- 
istry services within each community - to record services available within 
a community. Such a registry may be managed by a Service Peer, and sup- 
port service discovery within the community. Another related work is the 
referral mechanism for service discovery found in systems such as Chord 
and Tapestry ([3]). These rely on the use of overlay networks to minimise 
the number of search messages that need to be propagated to discover a ser- 
vice. Messages are often broadcast with a limited hop count or Time To Live 
(TTL) setting, to ensure that message traffic is constrained to the vicinity of 
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the requesting peer. Once again, we may establish an overlay network over 
our Service Peers to support service discovery between communities. Our 
approach does not preclude the use of such message forwarding techniques. 



2. COMMUNITY FORMATION 

Service based communities can be of many different types, with consid- 
erable research already having been undertaken in this area in the context of 
Multi-Agent Systems (MAS). The notion of what constitutes a community 
differs - with an emphasis ranging in scope from “functional" communities 
(those based on a particular application or problem domain) to those based 
on community “characteristics" (such as performance, trust/reputation, se- 
curity policy etc). Another distinguishing feature is whether the community 
structure is centered on the capability of individual participants, or the over- 
all objectives/goal of the community in its entirety. Work in Holonic MAS 
shares many similarities with the formation of communities ([5]), and in- 
volves the establishment of a community as a self-similar structure that can 
be repeated multiple times. Each peer in such a community undertakes a 
similar activity, although peers can exist at different levels of a hierarchy. 
Other descriptions of communities are based on the types of activities under- 
taken by its participants. When participants are cooperative, the community 
can be a “congregation”, a “coalition”, or a “team”. A congregation gener- 
ally consists of a meeting place, and the agents that assemble there (taken 
from the analogy of a club, a marketplace, a university department etc. in 
the context of human societies). Generally, members of such a congrega- 
tion have expended some initial effort to organise and describe themselves 
so that they are considered to be useful partners with whom others can in- 
teract. Hence, within a community of this kind, agents somewhat know 
about the capabilities of others, and take ‘for granted’ some of the attributes 
that the other agents may possess. ([2]) outlines how such congregations 
may form, and various other infrastructure services that need to be made 
available (such as a MatchMaking service, the location of a congregation 
meeting place etc). The usefulness of a congregation-based community is 
the limited effort each agent within such a community needs to expend once 
it has established itself into a congregation. Such communities are there- 
fore likely to involve repeated interactions and may generally exist over 
long time frames - as the whole point of developing such congregations is 
to allow an agent to have a greater level of trust in other participants (and 
therefore devote less resources to finding suitable partners for interaction). 
([8]) explore a formal model for specifying collaborative decision making, 
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Figure 8. 1. Hierarchical Communities 



in which agents coordinate their mental models to achieve a common group 
objective. They indicate that such a decision making will be impacted by 
the social nature of agents, which also motivates their particular behaviour. 
The formation of such a community involves agents which provide some 
commitment to the group in which they belong. 

For the work presented here, a community may be defined as a “collec- 
tion of agents/peers working towards some common objectives, or sharing 
some set of common beliefs". An agent may simultaneously belong to one 
or more communities, and must make a commitment to remain within a 
community for a particular duration. Each community may therefore be 
governed by a set of policy rules that all participants within the community 
must adhere to. These policy rules are managed by the Service Peer in 
the community - which is also responsible for ensuring that these rules are 
being adhered to. A policy may be presented to each joining peer during 
the community formation phase, and must be accepted prior to the peer 
being allowed to operate within the community. The Service Peer may also 
mediate interaction between peers within a community, and may support 
a number of common services (such as an “Event Service", a “Name Ser- 
vice", a “Resolver Service" etc). Groups may be defined, as illustrated in 
Figure 8.1 - the C5 community includes C1-C4. Similarly, a community 
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manager may share common services from a community at higher levels of 
the hierarchy (for C1,C2 for instance). In such a hierarchy, the community 
managers also act as gateways between multiple communities, and may fa- 
cilitate inter-group query forwarding. In this work we use the term “Service 
Peer" and Community manager synonymously. Community managers at a 
higher layer can interact and delegate activities to community managers at 
lower layers, and also register the address of lower layer community man- 
agers. Service and participant information is not replicated at higher layer 
community managers - simply the names of community managers who 
may then be able to provide additional details about participants within a 
community. The structure of such a community is significant, as it impacts 
the search time for locating particular services and peers. It is assumed that 
once an agent has agreed to participate within a community by agreeing to 
a policy, the agent is given a higher level of trust by other agents, and the 
community manager. However, enforcement of policy rules is not consid- 
ered here - and therefore the case where agents are malicious and violate 
policy rules is not considered. Hierarchical communities provide a useful 
way to structure interactions between peers, with each Service Peer acting 
as message relay to other communities - constrained by the policy rules 
operating in the community. 

The existence of a Service Peer is the minimum requirement to establish 
a community - as it allows the registration of new services, and keeps 
track of which peer(s) is (are) present within the community. We identify 
two concepts to illustrate how peers may be admitted to a newly formed 
community. The first of these is Expertise or Capability - and refers to 
one or more services that a particular peer offers. The fact that a peer has 
the ability to provide such services to others, allows us to associate such 
Expertise with the peer. The second concept relates to the Interests of peers 
within a community - and represents particular activities that a peer would 
like accomplished, but does not directly possess the Expertise to carry these 
out. Collaboration between peers is therefore also necessary to enable the 
Interests of a peer to be carried out (provided that there are other peers which 
provide the Expertise to do so). A new peer wishing to join a community 
must similarly meet the policy requirements (consisting of Expertise and 
Interests) identified by the Service Peer. If the Interests of a Service Peer are 
different from the Expertise being offered by a peer requesting membership, 
then the new peer is referred to other Service Peer/s, or the new peer tries 
to locate alternative Service Peer/s with compatible Interests. 

A Service Peer manages all peers within the community and commu- 
nicates with neighbouring Service Peers on the behalf of its members. A 




Quality-of-Service Based Grid Communities 



167 



Service Peer is also essential for the bootstrapping of a new peer, as it 
provides support for a new peer to discover enough network and compute 
resources to sustain itself within a community. A Service Peer may inter- 
act with a monitoring service within a community to achieve this. More 
generally, a Service Peer may therefore make use of other infrastructure 
services (such as monitoring, directory, security/certificate authority, etc) 
within each community. Such common services may be supported within 
a community, or may be external to a community and shared. Figure 8.1 
illustrates how these services are organised both within and outside a com- 
munity. 



2.1 Types of Communities 

Individual autonomous peers have Expertise and Interests in specific re- 
source/s. Based on these Expertise and Interests, peers may be grouped 
together within a single community. It is therefore possible to divide com- 
munities into the following types: 

■ Competing Community: In such a community each peer has the same 
Expertise - although some service attributes may vary. Similarity in 
services may develop competition amongst member peers, leading 
to a competition amongst peers to be selected for offering a service 
by the Service Peer. Competing communities enable the grouping 
of common services, and require a service provider to identify ways 
in which its own Expertise may be distinguished from those being 
offered by others in the same community. Each peer within such a 
community may be self-contained (i.e. be able to execute its own 
services). 

■ Cooperative Community: In such a community peers either provide 
different Expertise, or may offer a non-overlapping set of services. 
In such communities, each peer requires interaction with another lo- 
cal or external peer to execute services it manages. Hence, when one 
peer is selected, then the possibility of selecting another member peer 
is increased. This occurs because peers within a cooperative commu- 
nity are expected to be offering complementary services. When the 
services offered by one peer are utilised, it is likely that those of an- 
other member of the same community will also be needed. There may 
thus be a mutual dependence between peers within such a commu- 
nity, and the formation of these types of communities may be driven 
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by the mutual benefit in peers offering complementary services to 
come together. 

■ Goal Oriented Community: Such a community is similar to a Coop- 
erative community, and peers work together to achieve a particular 
goal. Membership in such a community is only allowed if the per- 
ceived Expertise offered by the joining peer allows the community 
to accomplish its goal. Such communities may be important in self- 
organising systems, where interactions between member peers are not 
pre-defined, but the services required are. In such instances, mem- 
ber peers may interact with each other in arbitrary ways to achieve a 
given end result. A goal oriented community differs from a coopera- 
tive community in that the goal being pursued may change over time 
- whereas the Expertise possessed by a cooperative community are 
likely to be static. 

■ Ad Hoc Community: Here peers can be in a co-operative or com- 
peting community, but need to work together as a team. In ad hoc 
communities, peers interact directly with' each other without interfer- 
ence and involvement of a Service Peer. Peers belonging to different 
communities providing different but supporting services form the ba- 
sis of an ad hoc community, as long as both concerned communities 
have agreed to use each other’s service. 

■ Domain-Oriented Community: Such a community is foimed by link- 
ing together similar-minded organisations and institutions, instead of 
the services they provide, such as a music sharing community, a 
research community, and an open-source community for a particu- 
lar type of software. Hence these communities are domain-oriented 
rather than service-oriented. 

Describing communities in terms of their Expertise and Interests in this way, 
allows us to map other related concepts to these. Hence, a Virtual Organi- 
sation (VO) may be mapped to a Cooperative or Goal oriented community 
- depending on how often the environment within which such a community 
exists changes. Similarly, a “market place” may be mapped to a compet- 
ing community, where different sellers and buyers operate to reach market 
equilibrium. 

The effectiveness of a community may be characterised via its “rating" 
by other Service Peers. Rating can be inter-community (i.e. the rating of 
one Service Peer by another Service Peer), or may be intra-community (i.e. 
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the rating of the Expertise of a peer belonging to a particular community 
by the Service Peer). We base our rating measure for a community on the 
number of requests sent to a peer by others. Hence, the greater the number 
of requests forwarded to a peer, the greater will be its rating. Such a metric 
provides a useful means to evaluate and compare communities offering 
similar Expertise. The use of a “Ratings" index is therefore a subjective 
measure of effectiveness - seen from the perspective of a service user. 



3. QOS-ENABLED COMMUNITIES 

As mentioned in section 2, a community is based on the Expertise and 
Interests of the Service Peer (acting as a community manager). Expertise 
and Interests can be “functional" - i.e. based on the names and parameter 
types of the services being provided or requested. If Web Service tech- 
nologies are being used, these names and parameters are generally encoded 
in the Web Services Description Language (WSDL), and associated with 
particular porttypes. An alternative set of Expertise and Interests relate to 
the “non-functional" properties, such as performance, trust/reputation and 
cost (for instance). Often, such non-functional properties are ignored, even 
though they may be significant in choosing and discovering a peer. We 
utilise particular types of non-functional properties related to the Quality 
of Service (QoS) offered by a peer. We may now extend the Expertise and 
Interests of peers with QoS attributes; thereby impacting all the different 
types of communities discussed previously. Hence, in a cooperative com- 
munity, peers may search for services which enable them to complete the 
execution of their service within pre-defined time constraints (thereby ne- 
cessitating the need to evaluate the Expertise of other peers with reference 
to their QoS attributes). Similarly, in competing communities peers may 
be able to distinguish themselves based on the QoS attributes they offer. 
QoS attributes in this context relate to network parameters associated with 
accessing a service, and execution parameters in running a service managed 
by a peer. For instance, network parameters include: 

■ Delay: this represents the time taken to deliver a message from a 
source to a destination peer 

■ Jitter: this represents the variation in the delay of messages being 
sent, along the same route, from a source to a destination peer 

■ Throughput: this represents the number of messages that are received 
by a destination peer within a particular time frame 
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■ Loss rate: this represents the number of messages that are lost or 
become corrupted within a particular time frame 

Each of these parameters can be monitored by the Service Peer. Similarly, 
parameters associated with service execution are related to the percentage 
of CPU time being allocated to a given service ([1]). We assume that by 
default communities are not QoS-enabled- as providing QoS support within 
a community is an overhead for the Service Peer. In this context, a QoS 
guarantee is essentially an agreement to provide a service according to an 
initially negotiated contract between a community manager (the Service 
Peer) and an external peer. An additional set of management activities are 
now required within a community to enable a Service Peer to offer such 
guarantees. 

A structure of a community is not static, and the Service Peer will try 
to adopt the structure based on changes in the environment in which the 
community exists. This is achieved by controlling the membership of peers 
that belong to the community. Communities which fail to adapt themselves 
will end up reducing their overall rating. As our rating measure is based 
on the number of forwarded requests to a community, we can make use 
of QoS attributes to measure how effectively these additional requests are 
being handled. As a community has a limited number of physical resources 
(network and CPU capacity), increasing the number of requests will also 
degrade the community QoS. Communities which are QoS enabled are 
better suited to providing such assurances - as the change in QoS due to 
increasing workload can be monitored. A Service Peer, for instance, may 
refuse to accept any additional requests if its QoS is likely to degrade. 

As not all communities are likely to be QoS enabled, it is necessary that 
Service Peers of only QoS enabled communities rate each other. A partic- 
ular community may decide to become QoS enabled when it has enough 
resources to work effectively even at high intra-community loads. If a com- 
munity cannot cope with this extra overhead, then it may badly affect the 
overall performance of the community. Furthermore, it is important that 
a community should have enough resources to provide the same service 
through different mechanisms, so that its QoS cannot be compromised due 
to the failure of a single peer. 

3.1 Properties of QoS-Enabled 
Communities 

QoS Enabled Communities only grant membership to peers which sup- 
port QoS assurance. When a peer wishes to join a QoS enabled community, 
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Figure 8.2. QoS enabled Community 

it must provide its initial QoS properties, and the associated performance 
information about its services. This information is stored in the Service 
Profile Repository (SPR), and activates a membership protocol. Figure 8.2 
illustrates a QoS enabled community - offering additional management ser- 
vices to enable the Service Peer to monitor and enforce QoS attributes. In 
such a community: 

1 Peers are created to provide specialist service/s (to enable the mea- 
surement of QoS attributes) along with basic/core services. 

2 Peers are physical hardware resources attached to the network. Two 
peers cannot represent a single hardware resource and vice versa. 

3 Peers which do not provide support for measuring and monitoring 
QoS attributes may not be allowed to participate in a QoS enabled 
community. 

4 Peers normally decide to become QoS enabled based on the type of 
community(ies) to which they belong. 

5 A QoS enabled peer may participate in any community. 

6 A community may decide to become QoS enabled to improve its 
rating. The rating of a community is related to the number of requests 
received by a community over a particular time frame. 
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Figure 8.3. QoS Negotiation 

As illustrated in Figure 8.2, QoS enabled communities have four additional 
components: 

■ The Service Profile Repository (SPR): can be a database or service 
registry. Its main role is to hold QoS related properties about services 
offered by a designated peer. For example, the service duration and 
service resource requirements are QoS properties. These properties 
are recorded/updated in the SPR in two forms: (a) On accepting 
membership of a new peer into the QoS enabled community - the peer 
must provide QoS properties of services offered, and these properties 
are entered in the SPR in the form of profiles for services, (b) On 
completion of a service by a client - in this case the QoS Monitor 
(QM) updates the profile in the SPR for this particular service. The 
update mechanism relies on the number of service(s) used, relate to 
the resources consumed during each service usage and the duration 
of service execution. 

■ The QoS Scheduler (QS): in a QoS enabled community, the QS works 
together with the service peer and the QoS Support module of a 
designated peer to provide services with QoS guarantees. Its main 
role is to receive requests from a service peer for services providing 
QoS assurance. The QS also indicates to a peer whether the service 
requested can be immediately honoured, or whether they are likely to 
be delayed -depending on the existing schedule that it maintains. The 
QS undertakes a QoS negotiation process with the designated peer. 
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with QoS properties obtained from the Service Profile Repository 
(SPR) for the requested service. The result of the negotiation process 
is the reply to the service peer - which the service peer can then use 
to admit, or reject, a client’s QoS-based service request. Figure 8.3 
illustrates the negotiation protocol. 

■ QoS Monitor (QM): this is used to track the execution pattern of each 
service and gather performance characteristics for QoS requirements. 
It uses this information to update profiles in the SPR, for use by the 
QS when needed. 

■ The QoS Module: this component is managed by the Service Peer, 
and provides a QoS management function to enable QoS negotiation, 
advance/immediate resource reservation, resource allocation/release 
and an agreement protocol to confirm resource reservation. The QoS 
Module provides a guaranteed execution environment for services, 
described in terms of resource requirements, the starting time of the 
execution, and the likely duration for which a particular resource may 
be needed. The resource requirements can be expressed in terms of 
‘compute’, or CPU specifications - such a CPU specification consists 
of: (a) the total compute power, or (b) a specific compute slot offered 
by the peer. The four QoS management subsystems providing the 
required assurances are: 

1 QoS Manager: this is the interface for the QoS management 
system. The QoS Scheduler (QS) interacts with the QoS system 
through this interface. It accepts requests for QoS services and 
orchestrates the request between the components of the system, 
and then generates a reply to the QS. 

2 Policy Manager: this provides the required dynamic informa- 
tion about resource characteristics offered by the peer, and pol- 
icy information of when, what and who is authorised to use the 
community resources. This information may be updated by the 
peer owner or the Service Peer. 

3 Reservation Manager: an abstract data structure that holds 
reservation entries for a particular resource(s). It does not inter- 
act directly with the resources, but obtains resource(s) charac- 
teristics from the Policy Manager. When a reservation request 
is received from the QoS manager, the reservation manager un- 
dertakes an admission control test to check the possibility of a 
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reservation promise to the requester. Similarly, for service ex- 
ecution, the QoS manager checks the reservation data structure 
for the reservation, and, subsequently, instructs the allocation 
manager to allocate the reserved resource(s). 

4 Allocation Manager: this module is used to interact with re- 
source managers for allocation and de-allocation of resources, 
based on requests from the QoS manager. A variety of re- 
source managers can be used; for example, a Dynamic Soft 
Real Time Scheduler (DSRT) ([7]) for allocating compute or 
CPU resource(s). 

3.2 QoS Enabled Peers 

As previously discussed, peers are not QoS enabled by default, but may 
decide to become QoS enabled when the communities to which they be- 
long start to support QoS constraints. This is achieved by the Service Peer 
within the community deciding to support additional services mentioned in 
section 3.1 above. QoS enabled communities can only have QoS enabled 
peers, and if any peer decides not to support this functionality, its member- 
ship may be terminated by the Service Peer. Each peer that belongs to a 
QoS enabled community must agree to provide performance data to one or 
more services managed by the Service Peer in the same community. This 
performance data includes parameters related to execution time/resource 
usage, and network parameters (such as bandwidth/latency. A peer may be 
a member of two communities in two situations, as follows: 

Case 1 : In this case, a peer is a member of both a QoS enabled and 
an un-enabled community. As a member of two communities, ser- 
vice requests are expected from two different types of Service Peers. 
A service request received from a Service Peer of the un-enabled 
community will be treated on a ‘best-effort’ basis, with the service 
executed when resources become available - in this instance, no as- 
surance on service execution is provided. The following scenarios 
could occur: 

■ A request is received while no other services are running on the 
peer, and the ‘best effort’ mechanism will make use of the all 
the available resources to execute the service. 

■ A request is received while a ‘guaranteed’ service(s) is/are run- 
ning on the peer belonging to the QoS enabled community. The 
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new request is now scheduled to run on the remaining resources 
- if any are available after responding to the requests from the 
QoS enabled community. The implication is that unpredictable 
execution patterns may occur for services that do not provide 
QoS data; for example, the service might take a long time be- 
cause of insufficient resources, or might run normally as the 
available resource is sufficient - no prior guarantee as to which 
mode of execution is used can be made. 

■ A request is received while a guaranteed service(s) is utilising 
close on 100% of the compute resource. Here the ‘best effort’ 
service will not be immediately executed, and will have to wait 
until the resource is released by the ’guaranteed’ service. 

Case 2: In this case, a peer may be a member of two QoS enabled commu- 
nities, and requests are expected from two different QoS Schedulers 
(QSs). The QoS management system operates on the concept of a 
‘First In - First Out (FIFO)’ scheduling mechanism. When either of 
the QSs attempts to negotiate for QoS requirements, the QoS manager 
passes the request to the reservation manager, which in turn runs an 
admission control test to check the feasibility of granting this request. 
If the request cannot be admitted, a reject message is sent to the QS 
with a proposal for the next available time, and it is up to the QS to 
accept or discard. On the other hand, if the request is granted, an 
accept message is returned to the QS for confirmation or rejection. 

Although QoS guarantee is a desirable feature it has associated drawbacks 
- viewed as trade-offs for the promised assurance. The QoS overhead can 
be classified into: 

■ Request protocol overhead: The request protocol overhead is when 
the Service Peer receives a request for service but the request does 
not propagate directly to the peer who provides the service; it goes to 
the QS. The QS then goes through the negotiation process as outlined 
above. The negotiation process may succeed or fail. This negotiation 
process is a request protocol overhead. 

■ Execution protocol overhead: Similarly, during service execution, 
when the QoS manager receives a service execution request, it does 
not start the service directly, but goes though an execution admission 
test, which checks if the required resources have been reserved. This 
is viewed as an execution protocol overhead. 
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Figure 8.4. Protocol for joining a QoS enabled community 



It can be argued that this protocol overhead is a compromise to the assurance 
promised, otherwise if the ‘best effort’ execution is chosen, no guarantee 
on execution times can be provided. We envision associating a cost model 
with the ‘guaranteed’ services, so this cost factor will play a major role in 
assisting clients to select their best option - and is used to influence the 
service rating mentioned in section 2.1. Figure 8.4 illustrates the Join 
protocol. 



4. IMPLEMENTATION STATUS 

The central idea of a community is implemented using the JXTA li- 
brary ([12]) from Sun Microsystems - which enables the development of 
Peer-2-Peer systems in Java. In our implementation, each community is 
therefore essentially a JXTA group, consisting of a collection of peers and 
a Rendezvous peer (which provides some of the functionality of the Ser- 
vice Peer), along with a collection of common services (such as a registry 
service). Each peer on joining the community registers its expertise - as 
a collection of service signatures specified in XML with the Service Peer. 
These service signatures utilise a data model that is specific to the application 
domain within which the service exists. We currently provide a place holder 
for these service signatures, but do not necessitate any particular format for 
their descriptions (an illustrative example is provided in Code Segment 4b). 
At any point in time, the Service Peer has a list of all the services that are 
available within the particular group that it manages - therefore each peer 
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Figure 8.5. A JXTA Community Manager: User Interface 



registration within the group leads to an update of the PeerGroup adver- 
tisement managed by the Service Peer. The peer joining the JXTA Group is 
also allocated a unique identity by the Service Peer. Each JXTA Group has 
a sorted list of its member peers, and each peer present within this group 
has a sorted list of Groups to which it belongs. 

External peers apply for membership by sending their service advertise- 
ment to the Service Peer (this is done when a peer is first created - or 
when a peer wishes to change its current group), and selection is then based 
on the type of community that the Service Peer is managing (competitive, 
cooperative, etc - as outlined in section 2.1). The rate at which advertise- 
ments are being sent from a peer may be on a periodic basis, or may be 
stimulated by events such as a new peer joining/leaving the peer Group, 
or geographical information indicating the other services that are offered 
at a particular location, etc. Each peer has its own thread of control, and 
decisions regarding when an advertisement should be published is left to the 
peer owner/developer. Each peer must also provide a listener interface that 
can be implemented and registered with the Service Peer. Using the listener 
interface, a peer can register interest in other peers that are also registered 
with the Service Peer (within the same community) - and the identity of the 
registering peer is used to propagate subsequent event information to it. 

A Service Peer may terminate the membership of a peer at any time - 
and a peer may decide to leave a group at any time. We assume in our 
implementation that the identity of a peer (and a group) does not change 
over time. To support group management, we provide an interface that 
enables a developer to view the current state of the group at any time - 
this is illustrated in figure 8.5. Each Peer advertisement (provided in Code 
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Segment 1) contains both optional and mandatory elements. The mandatory 
elements are PID (peer identity), GID (group identity), Name (peer name), 
and Desc (summary of peer expertise). The other elements, such as Dbg 
(debug) and Svc (service description) are optional - hence, it is possible in 
our scheme to have peers which provide no service. A peer may not provide 
any service when it first joins a community, for instance - and therefore the 
Svc elements may be blank. Subsequently, once a peer has been part of a 
community for a particular duration, it may issue a new peer advertisement 
(using the same PID as before) and advertise its new services. The use 
of blank Svc elements within a peer advertisement may be useful when 
bootstrapping a community. The peer advertisement is seen by all the peers 
within the same community, and also by the Service Peer - restricted by 
the GID. Each peer advertisement can contain multiple Svc elements. The 
Service section may also optionally contain an element isOff meaning 
that this service is disabled. This element is used to convey a configuration 
choice made by the owner of the peer. The Svc element may contain details 
about a particular expertise held by the peer, or may be a reference to 
a service maintained in some repository. For instance, such a reference 
may point to a service maintained in a UDDI registry. Each of these Svc 
elements describe the association between a group service denoted by its 
MCID (Module Class ID), and arbitrary parameters encapsulated in a Param 
element. The MCID is essentially a service identity that uniquely identifies 
a given service - even though the service may be provided by different 
peers. The MCID may also acts as a service name - and is generated by 
a running a factory service with a URL reference to the service location 
- which returns a unique identity for the service at the specified location. 
The Param elements should specify the exact set of parameters (and their 
ordering) that need to be sent to a service - and must also specify the types of 
return parameters that are sent in response. There is no mechanism in JXTA 
to specify which parameters are inputs or outputs in the Peer advertisement 
(Code Segment 1), and it is therefore necessary for a service provider to 
specify this information in the Module Specification advertisement (Code 
Segment 3). A Module Specification advertisement may also specify how 
to invoke and use a service. 

Code Segment 2 and 3 identify a way to describe Module Class IDs. 
Each such ID must have a name and unique description, and must specify a 
way to invoke the service - through a JXTA “pipe" (equivalent to a named 
communication channel). There are also other ways in which the service 
could be invoked (other than the use of a JXTA pipe - although this is as- 
sumed to be the default mechanism), such as use of Java RMI or via a SOAP 
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message. In the case of invocation using SOAP, a URL to the location of 
the service needs to be provided. Each Module Specification Advertise- 
ment (Code Segment 3) can have multiple Module Implementations (Code 
Segment 4a). It is therefore possible to have multiple implementations for a 
service (with a particular MCID to exist. Whereas the Module Specification 
(Code Segment 3) only provides a higher level specification of the service, 
the Module Implementation (Code Segment 4a) needs to provide details of 
the exact bindings for invoking the service. Each service implementation 
for a particular MCID must have a unique MSID (Module Service ID) - as il- 
lustrated in Code Segment 4a. In this way, it is possible to uniquely identify 
an implementation for a particular service specification. 

<?xml version="l .0" encoding="UTF-8"?> 

< jxta : PA xmlns : jxta="http : // jxta . org" > 

<PID> . . . </PID> <GID> . . . </GID> 

<Name> . . . </Name> <Dbg> . . . </Dbg> <Desc> . . . </Desc> <Svc> 
<MCID> . . . </MCID> <Param>... </Param> </Svc> 

</jxta:PA> 



Code Segment 1: Peer Advertisement 



<?xml version="l .0" encoding="UTF-8" ?> 

<jxta:MCA> 

<MCID> . . . </MCID> <Name> . . . </Name> <Desc> . . . </Desc> 
</jxta:MCA> 

Code Segment 2: Module Class Advertisement 



<?xml version="l . 0" encoding="UTF-8" ?> 

<jxta:MSA> 

<MSID> . . . </MSID> <Name> . . . </Name> <Crtr> . . . </Crtr> 
<SURI> . . . </SURI> <Vers> . . . </Vers> <Desc> . . . </Desc> 
<Param> . . . </Param> 

<jxta:PipeAdvertisement>. . . </jxta:PipeAdvertisement> 
<Proxy> . . . </Proxy> <Auth> . . . </Auth> 

</jxta:MSA> 

Code Segment 3: Module Specification Advertisement 
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<?xml version="l . 0" encoding="UTF-8"?> 

<jxta:MIA> 

<MSID> . . . </MSID> <Comp>. . .</Comp> <Code> . . . </Code> 
<PURI> . . . </PURI> <Prov> . . . </Prov> <Desc> . . . </Desc> 
<Param> . . . </Param> 

</jxta:MIA> 

Code Segment 4a: Module Implementation Advertisement 

<?xml version="l .0" encoding="UTF-8"?> 

<library> 

<name>math . solvers . simple</name> 
<class>add</class> 

<param inval="2" outval="l"> 

<in type="f loat">?X</in> 

<in type="f loat">?Y</in> 

<out type="float">?Z</out> 

</param> 

</library> 

Code Segment 4b: Description of a Math Service 



As indicated in code segments 1-4, each peer belongs to one or more JXTA 
groups - and supports one or more services. A service may be directly 
provided by a peer and specified in its service advertisement, or alterna- 
tively the properties of a service may be registered within a UDDI registry 
service also provided within the same community. In the latter case, the 
advertisement of a peer contains a reference to the UDDI registry containing 
elements of the WSDL document for the service. 

Consider a peer within a community providing a Stock Quote service. 
This service should have an XML based advertisement so that other peers 
(within the same community) or the Service Peer can discover it, and for- 
ward requests to it. Code Segment 5 provides a user defined Stock Quote 
Advertisement. This description of a service differs from Code Segment 
2, as only one instance of such a user defined service can exist within a 
community. Hence, the format for service specification in Code Segment 
2 is the default format expected by JXTA - however Code Segment 5 il- 
lustrates how a user defined format can be used instead (with constraints 
on the number of implementations that can co-exist - in the case of Code 
Segment 5 this is restricted to one). 
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<?xml version="1.0 "encoding="UTF-8" ?> 

<StockQuoteAdvertisement><Name> . . . </Name><Desc>. . .</Desc> 
<Status>. . .</Status> 

</StockQuoteAdvertisement> 

Code Segment 5 : Stock Quote Service Advertisement 



The N ame element is used to encode a developer defined name for the service, 
the Desc element a (human readable) text string indicating what the service 
does, and the Status a developer defined element encoding the current 
state of the service. A peer creates a service advertisement by using an 
abstract class, mainly providing set and get methods to access the elements 
defined in the advertisement. Using these methods, it is possible to assign 
and retrieve values for particular elements within the advertisement. The 
abstract class must make use of a parser to analyse the structure of the 
advertisement in XML (i.e. retrieve the order in which XML elements are 
to be parsed, and subsequently processed). 

The abstract class and the parser are mainly used to process the adver- 
tisement. Additional code is needed to be able to publish and respond to 
discovery requests/queries from other peers. This is achieved by defining 
the publishService, and the discoveryEvent methods. Finally, an im- 
plementation is associated with the service (and is similar to the description 
in Code Segement4a). Only a single implementation can now be associated 
with the service advertisement. 

Figure 8.6(a) illustrates how a request to discover a service is propagated 
across different communities. Each peer within a community (including 
a Service Peer) can support an advert cache - which is searched before 
a request to discover a service is propagated to the Service Peer (intra- 
community) or to another community. As indicated in figure 8.6(b), once a 
service has been discovered in another community (via Service Peer 3), 
it is now necessary to locate the peer providing the matched service - 
this is achieved by the Resolver Query message. The response mes- 
sage contains the PID of the requesting peer and the HandlerName - the 
HandlerName is an aggregation consisting of a PID, the MCID and the MSID, 
and uniquely identifies a particular service implementation being offered by 
a particular peer. Code Segment 6 illustrates the structure of the Resolver 
Query message. 
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<?xml version="l .0 "encoding="UTF-8"?> 

<jxta: ResolverQuery xmlns : jxta="http : //jxta . org"> 
<HandlerName> . . . </HandlerName><Credential> . . . </Credential> 
<QueryID>. . . </QueryID> <SrcPeerID>. . . </SrcPeerID> 

<Query>. . .</Query> 

</jxta: ResolverQuery> 

Code Segment 6: Resolver Query message 



In order to now make use of a service, a peer sends a query either directly to 
the peer providing the service (in an Ad-Hoc community) or to the Service 
Peer (in the other types of communities). The query should be wrapped in 
the Resolver Query message (Code Segment 6), in our implementation 
we have java classes to allow query messages to contain both optional and 
mandatory parameters. This message should now contain the exact set of 
parameters needed to initiate this request - for the Stock Quote service, 
this is illustrated in Code Segment 7 - where the Min and Max elements 
refer to the minimum and maximum price for the stock on a particular 
Date. Subsequently, a Query Response is sent to the requesting peer - 
illustrated in Code Segment 8 for the Stock Quote service. 

<?xml version=" 1 . 0 ,, encoding= n UTF-8 lt ?> 

<InitiateStockRequest> 

<StockName>. . . </StockName> 

<Date> . . .</Date> <Min> . . . <Min> 

<Max><Max> 

</InitiateStockRequest> 



Code Segment 7: Stock Request Query 

<?xml version="l .0 "encoding= M UTF-8" ?> 
<jxta:ResolverResponse xmlns : jxta="http : //jxta. org M > 
<HandlerName> . . . </HandlerName> 

<Credential>. . . </Credential> <QueryID>. . .</QueryID> 
<Response> 

<StockData><StockName> . . . </StockName> 

<StockSymbol> . . . </StockSymbol> 

<link>http : //quote . yahoo . com/ q?s=SUNW</link> 

<price currency = ,, pounds ,l >20 . 59</price> 

<detail>. . .<detail> 

</StockData> 

</Response> 

</ j xta : ResolverResponse> 



Code Segment 8: Query Response message 




184 



There are therefore three kinds of services that exist within our implemen- 
tation of a community: 

1 Services that are implemented as Web Services: in this instance, it 
is necessary to provide a description of the service in WSDL, and 
requires each peer to provide a Tomcat server (and a SOAP client for 
accessing services on other peers). In this case, each peer is a service 
provider that is capable of managing one or more services. Service 
execution is now undertaken by the particular Web Services hosting 
environment being provided by the peer. The inclusion of such a peer 
exists within a JXTA group is primarily so that it can be combined 
with other peers - depending on the type of community it belongs to. 
Although such services may have QoS constraints specified, there is 
no guarantee that these constraints are likely to be observed. 

2 Services that are implemented with Java CoG Core ([ 1 1]): in this in- 
stance, each service interface must also be specified using a WSDL in- 
terface, but the execution of each service is managed via the CoG Core 
API. Each service now generates one or more Task objects - each 
of which has a unique TaskHandler. Using such a TaskHandler it 
is now possible to schedule these tasks on the resources managed by 
a single peer, or a collection of peers within the same JXTA group. 
Each such TaskHandler may be mapped to an MCID (in Code Seg- 
ment 2). To support QoS-enabled services, the Service Peer interacts 
with the Dynamic Soft Real Time Scheduler (DSRT) ([7]). If QoS 
guarantees are to be provided, it is now necessary for all services 
within the same community to be managed by DSRT. The Service 
Peer, in this instance, relinquishes control to this scheduling system. 
A Service Peer may pre-reserve resources based on likely demand 
from services within the community. Such demands for reservation 
are forwarded to the scheduler - which may accept or deny them based 
on the available resources and other services that are scheduled to run 
over a particular time frame. 

3 Services that are implemented with JXTA execution engine: in this 
instance, each service interface is implemented directly using the Svc 
elements, and each peer must provide its own execution environment. 
No guarantees are available that particular execution quality will be 
observed. Interaction between services take place using JXTA pipes 
- and service discovery is supported through the propagation of peer 
advertisement (within the community) or PeerGroup advertisements 
between communities. 
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5. CONCLUSION 

The concept of a “community” is a useful abstraction for grouping ser- 
vices. Communities can be of different types, and may support a variety of 
hosting environments. Each community has a “manager” responsible for 
admitting and releasing participants within it. Each participant within the 
community has its own thread of control - referred to as a “peer” - and may 
belong to multiple communities simultaneously. A community manager 
is responsible for allocating resource present within it, and for managing 
interactions with other communities. 

We implement this concept of a community as a JXTA group along with 
some common services made available to all participants within the group. 
In such a group, a Rendezvous peer is responsible for caching advertise- 
ments generated by peers that belong to the group. Each peer can either 
directly provide a service, or may utilise a third party execution engine. We 
illustrate how a particular type of hosting environment is necessary in order 
to support QoS guarantees within a community. However, we emphasise 
that it is important that not all communities may be QoS-enabled. 



NOTES 



1. The Global Grid Forum: See Web site at: http://www.gridforum.org/. Last visited: 

December 2003. 

2. The TeraGrid Project: See Web site at: http://www.teragrid.org/. Last visited: 

December 2003. 

3. The Globus Project: Argonne National Laboratory, Mathematics and Computer Science Division. 
See Web site at: http : //www . globus . org/. Last visited: December 2003. 
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Abstract The exploitation of Web Services in e-commerce is affected by their limited 
support for the interaction with the service consumers. The current standards for 
the publication of services fail to specify the conversation flow for the invocation 
of the operations; thus, only simple requests can be performed by the consumers. 

In this chapter, we present a conversation model supporting the management of 
long-lasting interactions between service provider and consumer, where several 
messages have to be exchanged before the service is completed. Other approaches 
assume that both the service producer and the consumer locally manage the con- 
textual information to carry out the conversation with the partner. In contrast, our 
model supports the consumers during the service invocation in order to simplify 
the establishment of short-term business relationships. Our approach is based on 
an interaction model derived by simplifying Speech- Act Theory. Moreover, the 
management of the conversation turns is based on the communication techniques 
proposed by the emerging standards for Web Services. 



1. INTRODUCTION 

Web Services are subject to several limitations that reduce their appli- 
cability to realistic domains. For instance, the emerging service publi- 
cation standards, such as WSDL (Web Services Description Language, 
(24)), support the specification of the static interfaces of elementary ser- 
vices. However, these standards do not enable the service provider to 
specify the order of the operations to be invoked by the consumer during 
service execution. Therefore, the only services that can be successfully 
provided are those requiring one-shot interactions with the consumers. 
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Moreover, these standards support the invocation of operations charac- 
terized by very specific signatures with fixed parameter lists. Although 
this is not a problem when the requirements for the service can be speci- 
fied by the consumer in a pre-determined way, it challenges the provision 
of highly interactive services. 

At the same time, current work on workflow management is focused 
on service composition in the Web, but the proposed approaches assume 
a very simple type of interaction with the suppliers whose services have 
to be invoked. For instance, BPEL4WS (Business Process Execution 
Language for Web Services, (9, 10)) supports complex service composi- 
tions. However, the management of the interaction only deals with low 
level communication issues such as transaction management; see (5). 

In order to make service execution possible even when the involved 
suppliers require complex interactions, service invocation has to be 
modeled as a long-lasting conversation where several messages are ex- 
changed before the service is completed; e.g., requirements acquisition, 
negotiation and other types of interaction. For instance, during the in- 
teraction with a Web Service configuring medium complexity items, the 
selection of the item features may require more than one step. Moreover, 
failures may occur and have to be repaired before the solution for the 
consumer is generated. Finally, in some cases, the Web Service may 
require suspending the interaction, e.g., waiting for a sub-supplier or a 
human operator to contribute to the generation of the solution. At the 
same time, the consumer should be able to match its own business logic 
to the provider’s logic. For instance, not only the provider, but also the 
consumer might need to suspend the interaction because it needs supple- 
mentary information from the customer before choosing certain product 
features. 

Note that a loosely coupled approach to the management of the inter- 
action is needed to support successful business interactions and, at the 
same time, enable the consumers to match the provider’s conversation 
requirements to their own business logic. Moreover, the communica- 
tion capabilities of service providers and consumers should be enhanced 
by means of a lightweight approach. This is particularly important for 
the consumers, which should be able to start e-business interactions 
with heterogeneous providers, also outside well established Business- 
to-Business relationships. 

In this chapter, we present a framework supporting the management 
of long-lasting interactions between Web Services providers and con- 
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sumers. Our aim was to enable the conversation participants to dynam- 
ically select the messages to be exchanged during the service execution 
and to suspend and resume the interaction according to their needs. Thus, 
we have adopted a conversational approach to the management of the 
interaction. In particular, we have taken the Speech-Act Theory model 
of dialog management (19, 8) as a starting point for the development of 
our conversation framework, which has then been simplified in order to 
support its integration with the emerging standards for the publication 
of Web Services. 

The rest of this chapter is organized as follows: Section 2 positions our 
proposal in the current research about Web Services. Section 3 describes 
a representation of conversation flow based on Speech Acts. Section 
4 presents our approach to the management of conversations between 
service consumers and providers. Section 5 describes the framework 
architecture and implementation. Section 6 compares our proposal to 
the related work and Section 7 concludes the chapter. 

2. MOTIVATIONS 

As the management of long-lasting interactions is recognized as a cen- 
tral issue for the provision of realistic services as Web Services, some 
XML-based standards for the specification of the conversation flow in e- 
business interactions with Web Services have been recently proposed and 
are submitted as W3C standards. Current approaches support the speci- 
fication of complex conversations. For instance, WSCL (Web Services 
Conversation Language (23)) and WSCI (Web Services Choreography 
Interface (3)) introduce an explicit representation of Web Services in- 
teraction processes, aimed at defining the admissible sequences of mes- 
sages to be exchanged. For this purpose, WSCL exploits a sequence 
diagram model that the service provider and the consumer should in- 
terpret to handle the conversation, while WSCI introduces the notion of 
interaction process, with the definition of timing constraints on the ser- 
vice invocation. Moreover, cpXML (IBM’s Conversation Support (13)) 
introduces an explicit notion of Conversational Policy as a machine read- 
able specification of a pattern of message exchange in a conversation, 
which can be used to steer the interaction with complex Web Services at 
the consumer application side. 
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Unfortunately, these approaches assume that the provider and the con- 
sumer separately maintain an internal record of the conversation state and 
that they autonomously manage the turn-taking activity and the selec- 
tion of the next conversation action to be performed. This assumption 
is problematic because, in order to guarantee that the consumer has the 
required interaction capabilities, a conversation automaton compatible 
with the one defined by the Service provider has to be provided at the 
consumer side. 

In order to support loosely-coupled communication between the ser- 
vice provider and its consumers, the consumer applications should be 
assisted in the invocation of operations. This means that only the service 
provider should be responsible for maintaining the state of the conversa- 
tion and identifying the eligible continuations. A flexible, but seamless 
conversation model is needed to support the dynamic invocation of Web 
Services and the present chapter contributes to the definition of this 
model. Before presenting our approach, we discuss the following issues 
essential to the identification of our contribution. 

■ We assume that the matching phase between service description 
and request has been performed and we focus on the service execu- 
tion phase. It should be noted that we leave out the matching phase 
because it represents an important task deserving separate treat- 
ment. On the one hand, the identification of the service provider 
can be seen as a separate activity, to be performed either directly, 
or by exploiting mediation agents; e.g., see (16). On the other 
hand, after a provider is identified, an explicit and possibly com- 
plex binding activity has to be carried out by the consumer in order 
to associate the operations to its own business logic. This activity 
may require the intervention of a human administrator, who has 
to carefully analyze the meaning of the operations and their ar- 
guments, possibly requiring the sharing of the underlying domain 
ontology with the Web Service. 

■ The management of conversations should not be confused with the 
service composition that, in the Web Services research, is typically 
handled by workflow engines, such as BPEL4WS. In fact, these 
are complementary to one another. In particular, the conversation 
management enriches the flexibility in the invocation of the indi- 
vidual suppliers whose services are composed by the consumer. 
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Figure 9.1. Speech- Act based interaction flow for the hotel booking service. 



3. A SPEECH- ACT BASED REPRESENTATION OF 
CONVERSATIONS 

Social behavior of human and software agents has been traditionally 
described by exploiting the notion of Speech Act as a way of performing 
actions by exploiting language; see (4) and (19) for details. In particu- 
lar, communicative behavior in task-oriented interactions has sometimes 
been described by means of finite state automata defining the admissible 
sequences of speech acts to be executed (21). Moreover, hierarchical 
scripts and plan-based approaches have been introduced to model goal- 
oriented behavior (8) and to separate the conversational behavior from the 
domain-dependent activities carried out by the agents (6, 18). Roughly 
speaking, the agents cooperating at a domain-level activity communicate 
with each other to coordinate their own internal processes and to verify 
the feasibility of the actions they have to perform. 

Web Services and their consumers can be modeled as interacting 
agents and similar approaches can be used to model conversational be- 
havior. In particular, the messages exchanged during the service exe- 
cution can be seen as conversational actions performed to carry out a 
task-oriented dialog between service consumer and provider. For the 
specification of the conversation flow, the roles of the participants have 
to be defined. Although multi-party conversations may be specified, in 
the following we concentrate on conversations between two participants 
and we define the Consumer and the Service Provider roles (multi-party 
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conversations can be handled in a straightforward way by defining addi- 
tional roles). 

As a concrete example, we consider a simple hotel booking service. 
Figure 9.1 shows a possible representation of the admissible turn se- 
quences in this service. Each action specifies a speech act representing a 
conversational turn performed by one of the participants. We have named 
the speech acts according to the FIPA specifications; see (1 1). 1 The first 
argument of a speech act represents the role filler that should perform the 
act, i.e., the agent sending the message. The second argument denotes 
the recipient and the third one represents the content of the speech act. 
The arcs represent the possible turn sequences and the actions having 
more than one output arc are mutually exclusive. The interaction starts 
with the Query-if action, where the consumer C asks the service provider 
P whether the hotel has at least nrOfRooms available rooms ( HasAvail - 
ableRooms( hotel, nrOfRooms)). The service provider may answer pos- 
itively (Inform) P, C, HasAvailableRooms) hotel, nrOfRooms))), or neg- 
atively (Inform) P, C, not)HasAvailableRooms(hotel, nrOfRooms)))). In 
the second case, the interaction has to be terminated. In the first case, 
the consumer may request to book a certain number of rooms by provid- 
ing a credit card number. The service provider may either provide the 
consumer with the reservation number or notify that the booking action 
has failed. 

The interaction flow specified in Figure 9. 1 is simpler than the hierar- 
chical plans applied to manage human-computer dialog; see (6). In fact, 
the types of interaction to be modeled are much simpler and predictable. 
At the same time, we want to minimize the amount of information that has 
to be understood by the consumer. For instance, we have not specified 
any preconditions on the conversation turns. Moreover, each partici- 
pant is not informed about the internal state of its party. Although these 
two types of information would help to predict the actions that will be 
performed by the other participant, the only type of information to be 
understood by the interactants is the correct sequence of speech acts that 
can be executed. 

The publication of the conversation script enables a consumer to re- 
quest the services provided by another agent by following a specific 
interaction flow. However, this approach is not applicable to the current 
situation of Web Services, for at least two reasons. First, the imposition 
of speech acts on Web Services, now publishing services by means of 
very simple languages such as RPC invocations or WSDL operations, is 
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not realistic. Second, the identification of the admissible reactions to the 
provider’s messages requires that the consumer keeps an internal rep- 
resentation of the interaction context which includes, at minimum, the 
current focus of the conversation, i.e., the most recently executed action. 
These requirements are not desirable because they impose supplemen- 
tary efforts on the consumer than those required to invoke standard Web 
Services. 



4. SERVER-SIDE CONVERSATION MANAGEMENT 

In order to support the management of lightweight and loosely coupled 
conversations, we propose to make the management of the interaction 
easier for the consumer, charging the service provider with the control 
of the service invocation. More specifically, we propose that: 

■ The service provider publishes the services by specifying the WSDL 
operations to be invoked. This enables the consumers to bind the 
invocations of operations to their own business logic. 

■ The specification of the interaction flow is based on a flexible, but 
simple representation formalism supporting the definition of the 
correct sequence of turns to be exchanged without the overhead of 
the pure speech -act model. 

■ The service provider maintains a local interaction context, for each 
active conversation, to guarantee that at least one of the participants 
controls the conversation. 

■ To make the consumer aware about the eligible actions it may 
perform, at each step, the provider enriches the messages it sends to 
the consumer with contextual and turn management information. 
The contextual information may be void in trivial interactions. 
The turn management information consists of the eligible actions 
(henceforth, next operations) that the consumer may perform to 
carry the interaction one step forward. 

4.1 Conversation Flow Specification 



The specification of the interaction flow can be simplified by model- 
ing the interaction turns as generic conversational activities where the 
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performed speech act ( Inform , Query-if, etc.) is omitted. Each conver- 
sational action represents a simplified speech act (19), where the sender 
asks the recipient to perform the operation specified as an argument. The 
conversational actions have the following arguments: 

■ The message sender, which may be either the consumer C, or the 
service provider P. 

■ The recipient of the message (similar). 

■ The requested operation, i.e., the operation that the sender invokes 
on the recipient by performing the speech act. The actor of the 
requested operation may be omitted because it coincides with the 
recipient of the message. 

■ The list of the possible continuations of the conversation ( nex - 
tOps). As the service provider has the control of the interaction, 
this argument is only present in the messages to be received by 
the consumer. The argument includes the set of operations of- 
fered by the provider which the consumer may invoke in the next 
conversation step. 

■ A context argument, storing information about the state of the 
interaction ( ctx ). Similar to the nextOps argument, the ctx one is 
only present in the messages directed to the consumer. 

The structure of the context argument depends on the application domain. 
The context object can be empty in simple and deterministic interactions, 
where the consumer has at most one conversation turn to choose from, 
i.e., the next operation argument of the includes at most one element. 
However, we introduced the context argument in the messages to support 
the development of consumers displaying different levels of initiative 
during the interaction with the Web Service. Although we cannot make 
any assumptions on the consumer’s decision capabilities, the binding 
activity in a complex consumer might concern the definition of conditions 
on the invocation of the operations on the service provider. For instance, 
the consumer might wish to inhibit the invocation of some operations 
before the interaction reaches a certain fulfillment state, to be specified 
in the contextual information. 

Figure 9.2 shows the simplified representation of the interaction flow 
in our hotel booking service. In the figure, the nodes represent conversa- 
tion turns and the arrows define the possible turn sequences. The nodes 
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Ini t Interact ion 

v^SendM(C,P, InitConversationJJJ^ 



Agreement * — 

J3endM(P,C, OK, nextOps, ctx]^P 



CheckAvailability 

SendM(C, P, CheckAvailableRooms (hotel , nrOfRooms]j]l> 





Confirmation -■- 

Sen dM(P,C, OK(res), nextOps, ctxi^ 




■ - — Booking ' ' N 

C^SendM(C,P, BookRooms (nrOf Rooms, hotel, cardNJJJ^ 




Error 

SendM(P,C, Fault (res, coinmienhJJJ^ 



Figure 9.2. Complete conversation flow for the hotel booking service. 



having more than one output arrow represent alternative conversational 
actions. As shown in the figure, an interaction is triggered by a consumer 
that sends a message to request the InitConversation action specified at 
the root node of the conversation script. This message starts the hand- 
shake between the participants and the provider may accept or refuse 
the conversation (see the successor nodes in the script), sending a noti- 
fication message. In the positive case, the conversation is carried out as 
specified in the script, otherwise it is terminated. Each conversation turn 
is represented as a send message ( SendM ) activity specifying the related 
arguments (the sender of the message, the recipient, etc.). For instance, 
Query-if(C, P, HasAvailableRooms(hotel, nrOfRooms)) in Figure 9.1 
corresponds to SendM(C, P, Che ckAvailableRooms( hotel, nrOfRooms )). 
Moreover, Inform(P, C, HasAvailableRooms( hotel, nrOfRooms)) is re- 
placed by SendM(P, C, OK(res), nextOps, ctx). 

Two kinds of operations may be the arguments of a conversation turn: 

■ Domain-level operations, such as CheckAvailableRooms and Book- 
Rooms, representing domain dependent operations to be invoked 
during the service execution. 

■ Communicative actions, such as InitConversation, OK, Fault, 
Suspend, Resume and Receive Re suit, that are domain-independent 
and have to be invoked during the service execution to coordinate 
the behavior of the service provider and consumer. 
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The communicative actions have to be offered by both the provider and 
the consumer. The domain-level operations are only offered by the ser- 
vice provider because they are concerned with the service execution. For 
instance, the Suspend and Resume actions, which can be invoked on the 
provider as well as on the consumer, are aimed at suspending a conver- 
sation and resuming it later on. Moreover, the ReceiveResult action has 
to be implemented by the consumer in order to collect the results of the 
operations performed by the provider. In the figure, the domain-level 
operations are show in boldface. 

4.2 Interaction Management 

The conversation flow specification enables a consumer to bind the 
invocation of the service operations to its own business logic, by associ- 
ating the invocation of operations to its own internal processes. However, 
the exhaustive specification of the conversation flow may be challeng- 
ing for highly interactive Web Services. For instance, consider a Web 
Service selling configurable items. The operations to be performed dur- 
ing the configuration process can be clearly defined, e.g., selecting the 
needed components, setting values for the features of the components, 
and so forth. However, the features whose values have to be set at each 
step cannot be a priori determined because they depend on the com- 
ponents required by the consumer and on the inferences performed by 
the configuration system employed by the Web Service. Therefore, the 
Web Service has to dynamically determine the operations that can be 
invoked during the exploration of the search space by taking contextual 
information about the interaction into account. 

The provider can enforce the run time interaction management by 
instructing the consumer about the operations to be invoked and their 
actual parameters. This is possible if, for each active interaction, the 
provider: 

■ Maintains a context object specifying contextual information, such 
as the current focus of the interaction. 

■ Exploits the conversation flow specification to identify, at each 
step, the possible continuations of the interaction. 

Given the script representing the conversation flow, the current focus is 
the node corresponding to the last speech act performed either by the 
service provider or by the consumer; see (6). 
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Ini t Interact ion 

SendM(C, P, InitConversation 
oroductCon figuration . 




Figure 9.3. A portion of the conversation script of the Configuration Web Service. 



When a consumer starts a conversation with the provider, the current 
focus is set to the root node of the script (Init Interaction). The provider 
then moves the current focus in the script according to the messages it 
sends or receives. When the consumer receives a message, it executes the 
requested operation. It then extracts the eligible continuations and selects 
the one to perform. Note that each turn is an asynchronous message 
that one of the participants performs to carry the conversation one step 
forward. If the message does not reach the recipient, the interaction is 
suspended, with a time out. 

4.3 Supporting the Consumer-Side Participation in the 
Interaction 

In the following, we describe our framework for the management of 
lightweight conversations between service consumers and providers. 
Figure 9.3 shows the script representing the conversation flow of a Web 
Service supporting the configuration of medium complexity products, 
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SendM message 




SendM message 


Message : 

Invoked operation; 




Message: OK ( " 11 ) 


Next operations : 




Next operations: 


Domain- level 




SetFeatures (nrOfGears) ; 


actions 




PostponeSet (nrOfGears) ; 


Communi cat ive 




Suspend (id) ; 


actions) ; 






Context ; 




Context : 

Current Focus : 

speci f y ( gear Box ) 
Achieved Activities: 
specify ( frame) 
specify (handle) 



Figure 9.4. Format of messages exchanged between service provider and consumer. 



such as bicycles. As shown in the figure, this service requires complex 
interactions between the participants. 2 For instance, the feature setting 
operation has to be invoked by the consumer several times, until the 
item is completely configured. When the consumer invokes the SetFea- 
tures operation ( SetFeat node) to specify a set of product features, such 
as the number of gears, the provider may respond in different ways. 
For instance, it may confirm that the configuration step was successful 
( Confirmation node) and enable another invocation of the SetFeatures 
operation to carry the configuration one step forward. Alternatively, the 
service provider may notify the consumer about a failure in the config- 
uration ( Failure ) and it may enable the selection of other values for the 
conflicting features. In the conversation script, the SetFeatures opera- 
tion has a formal parameter ( args ). This parameter has to be bound to 
the actual list of features set at each interaction step, depending on the 
evolution of the configuration process. 

Figure 9.4 sketches the format of the messages sent by the provider to 
the consumer during the configuration of a bicycle. 

■ On the left side, the figure shows the abstract structure of the SendM 
messages. In the depicted message structure, the sender and re- 
ceiver arguments are omitted because they are specified in the mes- 
sage header. More specifically, the messages representing the con- 
versation turns can be seamlessly extended with turn-management 
information. Being implemented as SOAP messages, this infor- 
mation can be added by including new parts within the message 
body (22). 
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<types> 

<schema targetNameSpace="http : // example . com/conf igBicycle . xsd" 
xmlns="http : //www. w3 . org/2001/XMLSchema"> 

<element name=" Set Features" type="SetFeatAct"/> 

<complexType name="SetFeatAct"> 

<element name=" feature" type=" Feature" min0ccurs="0" maxOccurs=" unbounded" /> 
</complexType> 

<complexType name="Feature"> 

<element name="f eatureName" type="string"/> 

<element name="f eatureValue" type=" Domain "/> 

<element name="f eatureDomain" type="Domain"/> 

</complexType> 

<complexType name=" Domain "> 

<choice> 

<element name="Int Interval" type-"IntIntervalDomain"/> 

<element name= "Boolean" type="BooleanDomain"/> 

</choice> 

</complexType> 

<complexType name="IntIntervalDomain"> 

<all> 

<element name=" upper Bound" type="integer"/> 

<element name=" lower Bound" type="integer"/> 

</all> 

</ compldxType> 

</schema> 

</types> 



Figure 9.5. XML-schema definition of the operations and of their arguments. 



■ On the right side, a sample instance message is shown. In the mes- 
sage, the provider sends a positive acknowledgment (OK) repre- 
senting the successful execution of a previously invoked operation. 
The provider also specifies that the consumer may invoke SetFea- 
tures to set the number of gears the consumer needs, PostponeSet 
to postpone the setting to a later stage of the interaction, or it may 
suspend the conversation. 

The execution of these operations is aimed at carrying out the con- 
figuration of the gear box ( Current Focus)-, moreover, the service 
has already configured the frame and the handle of the bicycle 
(Achieved Activities). 

The sample context object shown at the right side of Figure 9.4 sketches a 
possible representation of the completion state of service offered by our 
Configuration Web Service. During the interaction with a consumer, the 
context is enriched to show that new components of the bicycle have been 
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successfully configured. In this situation, the consumer could exploit the 
contextual information to select the most appropriate continuation of the 
interaction in an informed way, in contrast to a naive consumer. For in- 
stance, the informed consumer might wish to configure the brakes of the 
bicycle only after the gears have been configured. To achieve this behav- 
ior, when the consumer binds the service invocation to its own business 
logic, it should condition the invocation of SetFeatures( brakes ) to the 
fact that specify (gears) is included in the context as an achieved activity. 
Of course, this type of behavior is possible only if the following con- 
ditions are satisfied: the consumer manages the contextual information 
on its own and is able to subordinate the invocation of operations to the 
satisfaction of conditions on the context state. Moreover, the Configura- 
tion Web Service offers a PostponeSet operation enabling the consumer 
to postpone configuration decisions; this is important to reconcile the 
business logics of the two participants. 

4.4 Representing the Conversation Flow in XML 

A standard representation formalism is needed to publish the conver- 
sation scripts on the Web. We thus decided to exploit an XML dialect, 
which we defined by taking inspiration from the IBM’s WSFL (Web Ser- 
vices Flow Language, (14)) service composition language. As described 
in (2) our representation enables the specification of WSDL operations 
and the partial order relations between their invocation. 

Figure 9.5 shows a portion of the XML-schema defining the structure 
(operation-name and arguments) of the operations to be executed dur- 
ing the configuration of a bicycle. For instance, the SetFeatures oper- 
ation has an argument containing a list of Feature, which is a complex 
type composed of featureName, featureValue and featureDomain. The 
featureDomain element specifies the set of admissible values that the 
feature can take. For example, Domain can be an IntlntervalDomain 
with its upper and lower boundaries, a BooleanDomain , a StringEnu- 
merationDomain, and so forth. Note that the featureValue element, 
representing the current value of the feature, has Domain type; this is 
due to the fact that during the configuration process its original domain 
could be progressively restricted, until the final value is selected. 

For each operation, a WSDL declaration specifies binding and ports 
information. For brevity, we omit the complete WSDL specification of 
the operations, whose identifiers are reported as boldface labels in the 
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<flowModel name="Conf igurationFlow" serviceProviderType="Conf igurationService"> 

<serviceProvider name=" conf igServer" type="Conf igurationServiceWS"> 

<locator type="static" service="ourConf igServer . com" /> 

</ serviceProvider> 

<consumer name=" consumer" type=""/> 

<activity name="sendFeaturesSpecif ication"> 

<performedBy actor= :,r consumer"/> 

<implement> 

<export><target portType= M conf igServicePT" operation "SetFeat"/x/export> 
</ implement > 

</activity> 

<act ivity name= " sendFeaturesConf irmat ion" > 

<per f ormedBy act or= " conf igServer " /> 

<implement> 

<export> 

<target portType=" conf igServicePT" operation= "Confirmation" /> </export> 
</implement> 

</activity> 

<act ivity name= " sendEr r orMe s sage " > 

<perf ormedBy act or=" conf igServer " /> 

<implement> 

<export> <target portType=" conf igServicePT" oper at ion=" Error "/> </export> 
</ implement> 

</activity> 



<controlLink source="sendFeaturesSpecif ication" 

target= "sendFeaturesConf irmat ion" /> 
<controlLink source="sendFeatureSpecif ication" 

target=" sendErrorMessage " /> 
<controlLink sour ce= " s endFeature sConf irmat ion" 

target="sendFeatureSpecif ication" /> 
ccontrolLink source=" sendErrorMessage" target="sendFeatureSpecif ication"/> 

</f lowModel> 



Figure 9.6. Portion of the conversation flow for our Configuration Web Service. 

nodes of the conversation script. For instance, the SetFeatures operation 
in Figure 9.5 is embedded in the SetFeat WSDL operation. Figure 9.6 
shows a portion of the flow model for the Configuration Web Service: 

■ The serviceProvider and consumer elements characterize the two 
conversational roles and the peers filling the roles. 

■ Each activity to be earned out is defined by specifying the re- 
quested WSDL operation and the actor that should perform the 
activity. For instance, activity sendFeatureSpecification has to 
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Figure 9.7. Conversation framework. 



be performed by the consumer and has as its content the SetFeat 
WSDL operation. 

■ The controlLink elements define the partial order relations between 
activities. 

The activities represent the conversation turns and are performed by the 
message sender to trigger the execution of the operations specified as 
their arguments on the receiver. 



5. FRAMEWORK ARCHITECTURE AND 
IMPLEMENTATION 

In order to manage the conversation, the service provider and con- 
sumer should run, respectively, a Conversation Manager and a Conver- 
sation Client module; Figure 9.7 sketches the architecture of the proposed 
framework. 

■ The Conversation Manager would exploit the conversation script 
(see Figure 9.3) to control the service provider’s communicative 
behavior. For each interaction session, the Conversation Manager 
of the provider maintains the active state of the interaction as a 
description of the contextual information concerning the conver- 
sation. This information is needed to compute the next operations 
available to the consumer and to support other types of behavior, 
such as the suspension of a conversation and the subsequent restart. 
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■ The Conversation Client would parse the incoming messages and 
send back the responses. More specifically, it should facilitate 
the reception and interpretation of messages at the consumer side 
(by extracting the next operations and their actual parameters). 
Moreover, the Client should support the invocation of operations 
by performing generating and delivering the outbound messages 
to the provider. 



We are developing a set of Java libraries which facilitate the develop- 
ment of a Conversation Manager and a Conversation Client modules 
supporting the communication between Web Service providers and their 
consumers. 

In particular, a Java-based Conversation Manager module enables the 
Web Service provider to keep track of the asynchronous communication 
with the interacting consumer applications. The proposed architecture 
of the Web Service Provider is shown in Figure 9.7. A Servlet supports 
the (SOAP) HTTP-based communication with the consumer, by catching 
the incoming requests and forwarding them to the Conversation Manager 
for their management. Indeed, the Conversation Manager is the core of 
the Servlet listening to the incoming requests, invoking the appropri- 
ate components to execute the services and sending the SOAP response 
messages to the consumer applications. Depending on the binding to the 
Web Service provider’s business logic, this module can invoke different 
types of components to provide the service. For instance, a service could 
rely on an internal component, such as Component A in Figure 9.7, or 
on an external Supplier. The Conversation Manager may execute a con- 
versation flow automaton for the management of the interaction sessions 
with the consumers in order to compute the possible continuations of 
each interaction. Although an infrastructure supporting the definition 
of general purpose conversation automata is not yet available, we have 
developed a prototype Conversation Manager that implements the script 
shown in Figure 9.3 and that can be easily customized to satisfy the 
interaction requirements of different application domains. 

Our framework also supports the consumer by offering a Java-based 
Conversation Client that may be downloaded and run in order to handle 
the interaction with a Web Service. Similar to the Conversation Manager, 
the execution of the Client has the prerequisite that the consumer binds 
the invocation of the operations to its own business logic. 
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6. RELATED WORK 

The Semantic Web community (20) is defining standards for the pub- 
lication of Web Services aimed at overcoming the main limitations of 
WSDL and the ones of the emerging workflow management standards. 
The semantic approach differs from the pure XML-based ones because 
it specifies the domain ontology underlying the service, the meaning of 
the operations to be invoked and the service choreography. The main 
advantage is that the service offered by a provider may be unambigu- 
ously understood by the (UDDI) registries, therefore enhancing their 
capability to redirect consumers to the most suitable providers; see (15). 
In order to facilitate the interoperability between service consumers and 
providers, some recent work also proposes prototype infrastructures for 
the run-time conversation management. These infrastructures rely on 
the semantic representation of the services to guide the interaction, e.g., 
by instructing the consumer during the service invocation (17). 

Although the semantic Web approach is a promising solution to the 
interoperability in the internet, the current proposals are too complex to 
be applied in real-world examples. For instance, these approaches rely 
on sophisticated representations of the services to be invoked; although 
translation tools assist the binding to the consumers’ business logics, 
this remains a rather complex process. Moreover, the selection of the 
operations to be invoked, depending on the service choreography, is 
based on the exploitation of inference engines, such as rule-based ones, 
imposing relevant overhead on the management of the interaction. In 
our work we are deeply concerned with the scalability and applicability 
requirements of the Web. For this reason, we try to reduce the complexity 
imposed by semantic information as much as possible, and to handle the 
interaction between service consumer and provider in a lightweight way, 
at least at the consumer side. 

The same considerations are useful to relate our work to the previous 
Multi-Agent Systems research, which regulated the interaction between 
agents by defining coordination protocols such as the FIPA Contract Net 
(11) and JAFMAS conversations (7). Unfortunately, the application of 
these approaches to the current Web Services is not straightforward be- 
cause it requires agreement on non-standard communication languages 
and interaction protocols, as done in the AgentCities project (1). More- 
over, these approaches assume that each participant in the conversation 
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is able to adhere to the shared conversation protocol and this is a strong 
requirement for Web Service consumers. 

Our interaction model differs from the other XML-based proposals 
for the publication of Web Services, such as WSCL (23), WSCI (3) and 
cpXML (13), because they assume that each conversation participant 
separately maintains its own internal record of the conversation state. 
In contrast, we propose that only the service provider handles the state 
of the conversation and that the consumer application is assisted in the 
service invocation. Moreover, WSCL and WSCI conform to WSDL in 
the definition of request-response and solicit-response operations; thus, 
they cannot support a fine-grained specification of the conversation turns. 

Finally, as far as cpXML is concerned, the consumer and provider 
roles require the same effort from the conversational point of view. In 
contrast, we try to simplify the implementation of the consumer by sup- 
plying it with the minimum amount of information needed to interact 
with the provider. At the same time, our approach does not impose extra 
overhead on the service provider, for two reasons. First, the provider 
has to maintain the context for each interaction session, otherwise, it 
would not be able to correctly execute the service requests. Second, the 
provider knows the details of the execution of its own services. There- 
fore, it may guide the consumers during the management of complex 
interactions. 

Both cpXML and our work aim at decoupling the service provider 
and consumer’s business logics by mediating their interaction by means 
of the conversational activity. However, our model has the potential to 
separate the consumer from the provider in a clearer way because it does 
not require the execution of a particular conversation policy. 

7. DISCUSSION 

We have presented a conversation model supporting the management 
of long-lasting interactions between Web Service providers and con- 
sumers. Our model is based on the idea that the service provider should 
support the consumers in the service invocation, in order to guarantee that 
the operations are requested in the correct order and that their parameters 
are suitably instantiated by the consumer. These characteristics make our 
model particularly suited to the management of highly interactive Web 
Services, such as those supporting the customization of complex prod- 
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ucts and services, which define the eligible sequence of invocations at 
run time, depending on the evolution of the configuration process. 

As described in (2), our proposal builds on the Speech Acts The- 
ory (19) that represents communicative behavior as actions performed 
by an actor towards a recipient. Our representation does not support 
the specification of different types of Speech Acts, with their semantics 
(11). However, it clearly separates the conversational activity from the 
domain-specific behavior that is represented as object level actions the 
partners “talk about” during the interaction. The explicit representation 
of the conversation participants and of their social behavior supports 
the detailed and unambiguous specification of the possible sequences of 
interaction turns, at the granularity level of the individual messages to 
be exchanged. Moreover, the model is simplified in several aspects in 
order to take into account the applicability requirements that can seri- 
ously affect the usefulness of the model in real cases. Finally, our model 
clearly separates the issues concerning the internal implementation of 
a Web Service from the communication protocol defining the invoca- 
tion of its operations. As noted in (23) and (12), no knowledge about 
the implementation of the service providers should be needed to invoke 
them. 



NOTES 

1 . FIPA, the Foundation for Intelligent Physical Agents, is an international organization aimed at produc- 
ing software standards for heterogeneous and interacting agents and agent-based systems. More information 
about the organization can be found in (1 1). 

2. Sharing the ontology representing the product structure is necessary to let the consumer understand 
the individual product features to be set. 
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Abstract Web services are software components that can be accessed across the Internet. 

Workflows of Web services are a set of Web services that are executed in a 
structured way. This chapter introduces a workflow composer agent, which is 
able to compose Web service workflows, and more importantly, uses semantic 
descriptions of Web services in finding and matching Web services for a workflow. 
The matching operates on the preconditions, effects, inputs, and outputs and 
utilizes semantic Web service ontologies in finding semantically similar Web 
services. The workflow composition is illustrated with an example scenario. 



1. INTRODUCTION 

The Web, once solely a repository of static data, such as of text and 
images, is evolving into a provider of services [22]. In the future the Web 
will be increasingly dynamic in its nature, that is, services may be available 
infrequently, for instance based on the context of the service provider or 
the potential user. Furthermore, it is normal to expect that the Web services 
will be integrated as part of workflow processes [8], 

Web service is software that can process an XML document it receives 
through some combination of transport and application protocols [31]. The 
XML documents a Web service can process are described using an XML 
Schema [13]; processes in a Web service conversation must have access to 
the same schema, which in the Web services’ case is commonly described 
in a Web Services Description Language (WSDL) [10] document. 

In this chapter we discuss the composition of workflows of Web services. 
A workflow defines how a service — let it be for an end-user or a machine — 
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is realized. With a workflow we mean a set of tasks that are executed as 
defined in a workflow document. A task in the workflow refers to an external 
Web service, which implements the actual functionality of the task. Let us 
illustrate these relationships with a simple travel forecast service for an end- 
user, who wants to know if it will rain or not at her current location. Thus, 
the end-user service would be location-based weather forecast. To realize 
such a service, a workflow of two subsequent tasks are needed: locate the 
user and get a weather forecast for that location. These tasks could then be 
implemented by two Web services, which locate the user by the current cell 
in which her mobile phone is located, and provide a weather forecast for 
instance for the city to which the cell belongs, respectively. 

In our architecture the composition of workflows is done by a workflow 
composer agent. We have chosen to use software agent technology, because 
it forms a solid base for creating autonomous, goal oriented, and proactive 
software (see, [19]). After the initial request for composing a workflow, 
the workflow composer agent acts without end-user intervention. It also 
seeks to meet the goal of a complete workflow that fulfills the requested 
functionality, and in the case of some missing functionality, the workflow 
composer agent proactively searches for replacing functionality. 

The rest of this chapter is structured as follows. Section 2 gives back- 
ground information about ontologies, workflow languages, and workflow 
composition techniques. Section 3 introduces our entities in the Web service 
workflow composition. In Section 4 we describe the algorithm with which 
the Web service workflow can be composed using the semantic descriptions 
of the Web services. Section 5 gives an example scenario, which illustrates 
how the workflow composition can be applied in practise. In Section 6 we 
discuss some open issues and future work, and finally, Section 7 concludes 
this chapter. 



2. BACKGROUND 
2.1 Ontologies 

An ontology is an explicit specification of a conceptualization [15]. In 
an ontology the knowledge of a certain domain is represented formally as 
a set of objects and the relationships among them. Ontologies are useful 
when applying search and semantic matching for Web services. To illus- 
trate this, let us consider the following scenario (see Figure 10.1). A Web 
service SI that provides the location of a user’s mobile phone has so far 
been used in a positioning application. In the search arguments of SI we 
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Figure 10. 1. The mapping of inputs and outputs of SI and S2 to the ontology. 

specify that the inputs for the Web service should be the “phoneNumber”, 
and the output is “Location” of the phone. Unfortunately, SI is no longer 
available, and therefore a replacing Web service needs to be found for the 
positioning application. When searching for replacing Web service, an ex- 
act match is not found. However, a Web service S2, where the input is called 
“MSISDN”, and the outputs are “Longitude” and “Latitude”, is available. 
Without knowing anything about the semantics, we would discard this Web 
service in the first place. However, if we would have a ontology defining 
that “MSISDN is-kind-of phoneNumber” and “Location is-composed-of 
longitude and latitude”, we could see that in fact the found S2 would serve 
our needs, and could be used by the positioning application. 

The DARPA Agent Markup Language (DAML) [16] is an ontology lan- 
guage for expressing sophisticated class definitions and properties. The 
DAML-S [2] is a DAML-based Web service ontology, which specifies how 
a Web service can be supplemented with a semantic description. The up- 
coming versions of DAML-S will be based on OWL [6], which is specified 
by the World Wide Web Consortium (W3C). Therefore, the DAML-S will 
also smoothly transform into OWL-S. The OWL-S is divided into three 
parts: a service profile, a process model, and a grounding. The service 
profile is used for advertising and discovering services, that is, it describes 
the service in terms of its inputs, outputs, preconditions and the effects it 
has once it is executed. The process model gives a detailed description of 
a service’s operation and describes how the service should be used. While 
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the service profile and the process model are abstract descriptions of the 
service, the grounding on the other hand provides concrete details on how 
to interoperate with a service. For instance, in DAML-S the grounding can 
be binded to WSDL, which in turn allows the interoperability within the 
Web service world. 

Later in this chapter we will show how a semantically annotated service 
profile plays an essential role when finding semantically similar Web ser- 
vices while composing workflows of Web services. This service profile 
could be expressed for instance using OWL-S. 

2.2 Business Process Languages for Web Services 

The interaction model that is directly supported by the core Web ser- 
vice standards — WSDL and SOAP [23] — is essentially a stateless model of 
synchronous or uncorrelated asynchronous interactions. Services offered 
for instance to mobile end-users typically involve sequences of message ex- 
changes, both synchronous and asynchronous, within stateful, long-running 
interactions involving two or more parties. For instance, a positioning ser- 
vice includes tasks such as locating the user, drawing the map of the location, 
and charging the user. To define such interactions, a formal description of 
the message exchange protocols used by business processes in their inter- 
actions is needed. 

Recently, a number of business process languages for Web services 
have emerged. These languages include Business Process Execution Lan- 
guage for Web Services (BPEL4WS) [1], Web Service Choreography In- 
terface (WSCI) [4], Business Process Modeling Language (BPML) [3], 
Business Process Specification Schema (BPSS) [30], Web Services Conver- 
sation Language (WSCL) [5], and XML Processing Description Language 
(XPDL) [32]. 

Of these, we are concentrating on BPEL4WS, because it allows a cen- 
tralized definition of the workflow, it builds on top of WSDL, and there are 
tools available for executing BPEL4WS workflows. BPEL4WS depends 
on WSDL, XML Schema [13], and XPath [11]. BPEL4WS represents 
the combination of two previously competing standards: XML business 
process language (XLANG) [29] from Microsoft, and Web Services Flow 
Language (WSFL) [20] from IBM. In BPEL4WS the external Web services 
are identified as partners. When creating a workflow dynamically, the part- 
ner section is created based on Web services that have been found during 
semantic matching. Variables contain the data that flows within the work- 
flow, and are based on the Web services’ inputs and outputs. Other features 
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<process name= M TheProcess"> 

<partners> 

<! — the external Web services invoked from within the 
workflow — > 

</partners> 

<variables> 

<! — specifies the data elements that flow within the 
workflow — > 

</variables> 

<correlationSets> 

<! — the bindings for a set of operations to a service 
instance — > 

</correlationSets> 

<faultHandlers> 

<! — lists the elements to catch faults — > 

</f ault Handler s> 

<compensationHandler> 

<! — specifies the elements that implement compensating 
actions in the case of transaction rollback — > 
</compensat ionHandler> 

<eventHandlers> 

<! — for receiving external events to the workflow — > 
</eventHandlers> 

<sequence> 

<! — the workflow execution logic — > 

</sequence> 

</process> 



Figure 10.2. The general structure of BPEL4WS workflow definition. 



of BPEL4WS include correlation, exception handling, compensation, event 
handling and control flow structures. Figure 10.2 shows a general structure 
of a BPEL4WS workflow. 

2.3 Approaches to Workflow Composition 

The area of workflow composition can be divided in three cases: pre- 
defined workflow with pre-defined tasks, pre-defined workflow with on- 
demand selection of tasks, and on-demand composition of the whole work- 
flow. The first case operates on static information; the workflow and the 
tasks — Web services in our case — are pre-defined while the workflow is de- 
fined. We do not see this case as an interesting one. This chapter addresses 
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the last two cases, and in the following we shortly describe the related work 
on these areas. 

In the second case we can have a system, where the workflow is already 
defined, but the Web services for it are selected at runtime. For instance, a 
workflow for reserving a trip could include a task for renting a car. It could 
happen that at the time of workflow invocation the car rental Web service 
used so far is disconnected from Internet, thus making it unavailable to 
the workflow. In this case another car rental Web services needs to be 
selected. There are several projects addressing the on-demand selection of 
Web services to a pre-defined workflow, such as Self-Serv [7], eFLOW [9], 
CMI [27], and the work by Mandell and Mcllraith [21]. 

In the third case a brand new workflow can be generated, and the Web 
services for it are searched. This is the case where the workflow is generated 
to meet a certain goal, and the Web services for the workflow are not known 
beforehand. To our knowledge, there has not been much research done on 
this area. Wu et al use AI planning techniques for automated composition of 
Web services [33]. Their work is based on SHOP2, which is a hierarchical 
task network (HTN) planner, which they use for planning over DAML-S 
descriptions. The objective is to create compound Web services with little 
or no direct human intervention. In [28] the authors present a planner that 
composes atomic services described in DAML-S into a composite service. 
The planner is implemented as a set of Java Expert System Shell (JESS) [14] 
rules that translate DAML-S descriptions (the query) of atomic services into 
planning operators. After this, the Web services satisfying the goal are added 
to the plan. 

In either of the last two cases, it may happen that one or more Web services 
in the workflow are unavailable at the time of invocation, thus, it is required 
to search and find a replacing Web service(s) to complete the workflow. In 
this chapter though we do not address the reasons of why a Web service 
may be unavailable. The replacing Web service(s) must implement similar 
enough functionality to the one that is to be replaced. To find such Web 
services the idea of Web service containers could be utilized [7]. Because 
Web services are deployed by various organizations world-wide, in reality 
it is unlikely to find a semantically perfect match for a Web service. When 
two Web services match perfectly, their 1) preconditions and effects for the 
“state of the world” are the same, and 2) they have exactly the same number 
and the same type of input and output parameters. 
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3. ELEMENTS IN THE WORKFLOW COMPOSITION 

Figure 10.3 depicts our entities of the Web service composition model 
and the information flow between them. Before the workflows of Web 
services can be composed, there has to be semantically annotated Web 
services available to the system. The Web services are both implemented 
and advertised by Web service providers (la, lb). After this — or at the 
same time — the Web service is annotated (i.e., the semantic description of 
it is produced), and the annotation is stored into the semantic description 
database (1 c). It should be noted that the Web service provider and annotator 
are usually the same entity, but in some cases an existing Web service can 
be annotated at some point after the Web service is advertised. By keeping 
a clean separation between the Web services and the semantic descriptions 
of the Web services we gain at least two benefits: 1) we do not require 
any modifications to the existing Web services, and 2) we can annotate 
the existing Web services at any time after the Web service is implemented. 
However, as the dashed line in Figure 10.3 shows, the semantic descriptions 
have to have a reference to the corresponding Web services. 

The workflow template repository contains “skeleton” workflows, which 
are not mapped to any concrete Web services, but instead, to semantic 
descriptions of Web services. When the workflow composer agent begins 
to compose a workflow, it retrieves workflow templates from the repository 
(2a). Each workflow is composed of one or more Web services, which 
can be situated anywhere on the Web. The semantic descriptions of the 
Web services are fetched from the semantic description database (2b), and 
the semantic matching between the semantic descriptions is applied. Once 
the workflow composer agent has matched the semantic descriptions for 
the workflow, it queries the WSDL interfaces of those Web services from 
the Web service directory (3). After this, the workflow composer agent 
composes the executable workflow, and feeds it into the workflow execution 
engine (4). Finally, the execution engine executes the workflow using the 
Web service implementations (5). 

There are two cases to consider when the workflow composer agent is 
asked to compose a workflow: 1) the workflow template is known, but 
the Web services for it have to be found, and 2) the query only specifies 
preconditions that are known, and the effects that should be achieved. In 
the following, both of these options are discussed in detail. 
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Web Service instances 




4. THE PROCESS OF COMPOSING WORKFLOWS 
OF WEB SERVICES 

The Web services may be available more or less infrequently, either be- 
cause of a physical or logical reasons. In the former case a network node 
hosting the Web service could be disconnected. In the latter case the avail- 
ability depends on the internal state of a Web service. For instance, a Web 
service of a restaurant could be unavailable for a user trying to book a table, 
if the restaurant is full at that time. When a workflow is composed of such 
Web services, it may happen that at the time of initiating the workflow, one 
or more of the Web services are unavailable. Should this happen, a similar 
functionality, implemented by one or more Web services, should be found. 
In addition to replacing unavailable Web services in a workflow, there might 
be a need to compose a whole new workflow, or extend an existing workflow 
to cover new Web services. 
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Figure 10.4. The general process of composing workflows. 



The process of finding a Web service to replace an unavailable one in 
some workflow or creating a whole new workflow can be presented as a 
flowchart as depicted in Figure 10.4. In the following, each of the steps are 
described in more detail. 

4.1 Processing the Query 

The first task is to identify the general functionality that should be ac- 
complished. This originates from the query, which may either refer to some 
workflow template or just specify a set of effects, which need to be achieved. 
In the former case the workflow composer agent only needs to select an ap- 
propriate template from the workflow template repository, and proceed to 
matching the Web services composing it. An example of this case could be 
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a situation in which a car gets broken on the road. The system could have 
a workflow template, which states the following semantic descriptions for 
services: locate the car (user), find the nearest garage, order a towing ser- 
vice, and call for a transportation for the user. Once the user has selected the 
workflow to be executed, the workflow composer agent proceeds to match 
the services to implement the workflow. 

The latter case is more complicated, because the workflow composer 
agent first needs to come up with a set of semantic descriptions, which 
together realize the required effects (see Section 4.2). Once this has been 
done, the workflow composer agent creates a workflow template based on 
the semantic descriptions, optionally stores the template workflow to the 
repository for later use, and finally executes the workflow. Referring to 
the previous example, in this case the user does not select any existing 
workflow template, but instead states her problem to the system in the 
form of preconditions and required effects. Based on these, the workflow 
composer agent matches the Web services, and composes a workflow. 

4.2 Semantic Matching of Web Services 

Semantic matching can be divided into two parts: finding the Web ser- 
vice^) that fulfill(s) the preconditions and effects of the needed function- 
ality, and finding the Web service(s) that accept(s) the required input and 
output arguments. To make this possible, the available Web services are 
annotated using semantic descriptions, which are stored in the semantic 
description database. Furthermore, the preconditions, effects, inputs and 
outputs refer to a domain ontology. 

Preconditions specify the things in the world that have to be true before 
the Web service can be executed. The effects specify, how the Web service 
alters the world when executing. In our system, when an unavailable Web 
service is to be replaced, the replacing functionality — let it be a single 
Web service, or a set of Web services executed as a composed service — 
must have the same preconditions and effects. The algorithm of matching 
the preconditions and effects consists of two steps: 1) find all the Web 
services that have one or more same effects as in the query, 2) select a set 
of Web services that satisfy the preconditions and effects of the query. This 
algorithm is not scalable, and is applicable only with a limited number of 
Web services. It also does not take into account that 1) the effects may be 
conditional, that is, they are not known at the time of composition, and 2) 
more than one Web service may be needed to satisfy a single effect. Our 
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intention in the future is to further develop the algorithm to cover these 
issues as well. 

While the similar preconditions and effects generally are enough, in prac- 
tise the input and output arguments need also be matched. This step follows 
the ideas of Paolucci et al [25], where the semantic matching algorithms 
for input and output arguments are presented. 

The preconditions, effects, inputs and outputs in both the advertisement 
and the query refer to an ontology, and the similarity is evaluated by the 
relationships between the referred classes in the ontology. This results in 
that there can be four different kinds of matches [25]: 

■ Exact match — the requested service (i.e., the service specified in the 
query) and the advertisement refer to the same class in the ontology. 

■ Plug-in — the advertisement is more general than the requested ser- 
vice. 

■ Subsumes — the requested service is more general than the adver- 
tisement; in this case the advertisement cannot completely fulfill the 
requested service. 

■ Fail — -No subsumption relation between the search template and the 
advertisement can be found. 

In the case of exact match the advertised Web service can be used as 
such. However, in the case of plug-in and subsumption, the advertised 
Web service can be used, but some additional processing may be needed. 
The plug-in service produces more results than needed, thus, some kind of 
filtering is needed. The subsumed result is not complete, so the requester 
may need other Web services to complete the result set. 

4.3 Attaching the Web Services to the Workflow 

Assuming all the semantic descriptions matching the required function- 
ality are found, the next step is to define the workflow or update the existing 
one. This includes the attaching of the Web services to the workflow, and 
definition of the possible dependencies. 

If the composition of the workflow is about replacing unavailable Web 
services, this phase is trivial; only the partner section in the workflow needs 
to be updated to refer to the new Web services (i.e., to their WSDL doc- 
uments). However, if a new workflow is created, the workflow composer 
agent does not have an existing workflow template to work on, instead, it has 
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to create one based on the matched Web services. The matching algorithm 
gives the required Web services in the order of execution. Therefore, using 
this information together with the WSDL documents of the matched Web 
services, the workflow composer agent first creates the partner section and 
the variables, and then the actual execution sequence. In this chapter we are 
not discussing about how the correlations, fault handlers, compensations, 
and event handlers for the workflow could be generated automatically. We 
could assume that after the workflow composer agent has generated the 
“basic” workflow, the workflow template would be stored, and be extended 
later on, for instance, by a human user. 

4.4 Executing and Monitoring the Workflow 

Once the workflow is (re)defined, it can be executed by a workflow exe- 
cution engine, which executes the workflow as defined, using the external 
Web services. The workflow execution engines usually provide tools for 
monitoring the execution of the workflows, and for verifying the output of 
the workflow. The executing and monitoring of workflows is uninteresting 
from this chapter’s viewpoint, and existing tools can be used for this phase. 
To our knowledge, there are at least two implementations of a BPEL4WS en- 
gine: BPWS4J (IBM) [18], and BPEL Orchestration Server (Collaxa) [12]. 
The former is available as open-source distribution, whereas the latter is a 
commercial product. 



5. EXAMPLE SCENARIO 

Let us illustrate the workflow composition with the following scenario, 
where a traveler is on a vacation, and asks for restaurants near her current 
location. Furthermore, the restaurants should be pointed on a map. During 
the execution of the scenario, the workflow composer agent refers to an 
ontology, which is depicted in Figure 10.5. 

There is a workflow template for the required functionality, and it is 
composed of two Web services: LocateMap and GetRestaurants. The 
LocateMap Web service takes the user’s phone number (MSISDN) and 
a diameter for a map as an argument, and provides a map — encoded for 
instance in a JPEG format — together with latitude and longitude of the 
center point as output arguments. The GetRestaurants Web service uses 
the latitude, longitude and map as the input arguments to add the nearby 
restaurants to the map. The workflow is depicted in Figure 10.6 (please 
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Figure 10.5. The ontology used in the example scenario. 




<partners> 

<partnt>r name="Lu<:fiteMap‘7> 

<partner na me="G*l Resin u rants"/!* 
</parttier*> 

< variables 

<variab]f name="'MSISDN7> 

<variable rmme="Dirtmeter“’/> 

< variable name-’Latit ude'7> 

<variable name^’Lon git ude^> 

<variable name^Map"^ 

<variable na mp=" Fi mil 0 u tput “/> 
</variabIei»> 

<scquence> 

< receive part nei^’iiser” /> 

<mvoke partner=n,xM:ateMap’7> 
cinvoke partnt*r=*’(itfttt('8laiirHnts7> 
<n?ply partner="'urfer u '/> 

</sequence> 



Figure 10.6 . The existing workflow for locating nearby restaurants. 



note that the BPEL4WS definition only includes the relevant information 
and therefore is not complete). 

In this scenario we will concentrate on the LocateMap Web service, 
which has the following preconditions and effects: 

[LocateMap] 

Preconditions: true(phone registered to the mobile network) A 

true( permission for positioning ) A 
true(phone supports JPEG images ) 

Effects: true( location known) A true( map available) 
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Furthermore, as shown in Figure 10.6, the LocateMap accepts MSISDN 
and diameter as the input arguments, and latitude, longitude and map as the 
output arguments. 

When the traveler makes a query for locating the nearby restaurants, it 
happens to be that the LocateMap is not available. Following the gen- 
eral process as depicted in Figure 10.4, the first thing for the workflow 
composer agent to do is to see if an existing template workflow is avail- 
able. The next task is to verify if the Web services for it — LocateMap and 
GetRestaurants — are available. As said, the former is not available, so 
the workflow composer agent proceeds to search for any Web service or 
Web services to replace the unavailable one by matching preconditions or 
effects that the LocateMap has. In this scenario there are three such Web 
services available: SI, S2, and S3. The preconditions and effects as well as 
input and output arguments for those services are as follows: 



[SI] 

Preconditions: 

Effects: 

Input: 

Output: 



true(phone registered to the mobile network ) A 
true(p emission for positioning ) 
true( location known) 

MSISDN 

location 



[S2] 

Preconditions: 

Effects: 

Input: 

Output: 



true(location known ) 

none 

location 

latitude A longitude 



[S3] 

Preconditions: 

Effects: 

Input: 

Output: 



true(phone supports JPEG images) 

true(map available) 

latitude A longitude A diameter 

map 



From the available Web services and their preconditions and effects the 
workflow composer agent can — during the matching phase- — infer the fol- 
lowing: 



■ The pre-conditions for SI are in order, because they are present in 
the query as well. 

■ SI fulfills the effect, true(location known), of LocateMap. 
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<pflrtners(> 

< partner name-’Srf> 

<partner name="S2*A> 

< partner name=*S3 ,, /> 

< partner name="GelRej)t«uranU _ /> 
</portners> 

<variableB> 

<vM(iHble name="MSISDN”A> 

< variable namo-“D] ameler'/> 
^variable name='"Locatic>n , 7> 

< variable name=Tjititude’ , /> 

< variable name=T-ongitude' , /> 

< variable name=*Map7> 

<variable name=' , FinalOutpuf‘/> 

</variables> 

<*#qu»n«> 

< receive partner^-uner"^ 

<in voice partner=“Sl“/> 

< invoke partner r “S27> 

<invoke partner=“S3"/> 

<invoke partner=' , GetRa*t*uraniJi , Y> 
< reply partner= - u*er , */> 

</sequence> 



Figure 10. 7. The new workflow for locating nearby restaurants. 



■ S2 has a pre-condition true(location known) but no effects. However, 
by inspecting the inputs and outputs, the workflow composer agent 
can use the S2 to convert the location into lat itude and longitude. 

■ S3 has pre-condition true(phone supports JPEG images), which is 
one of the effects of query. It also includes contains the true(map 
available) effect that is also one of the query’s. Therefore, S3, with 
SI, completes the preconditions and effects. 



What it comes to matching the input and output parameters, we already 
saw that the S2 is required because without it the input and output parameters 
would not match. However, if the workflow composer agent uses the ontol- 
ogy shown in Figure 10.5 while matching the input and output parameters, 
it could infer that the location aggregates both longitude and latitude. 
Therefore, the SI and S3 would be enough to replace the LocateMap. 

The diameter parameter in the LocateMap is fed into the S3 in the com- 
posed workflow. This can be done by using the variables in the BPEL4WS 
workflow definition. The other input and output parameters flow via the 
Web services through the workflow. 

Once the workflow composer agent has matched the Web services, and 
found out that they can be combined to replace the unavailable LocateMap, 
the Web services can be attached to the re-defined workflow as depicted in 
Figure 1 0.7 (the BPEL4WS definition only includes the relevant information 
and therefore is not complete). 
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6. DISCUSSION 

The semantic matching phase (see Section 4.2) plays a central role in the 
success of the workflow composition. Because Web services are deployed 
by various people world-wide, in reality it is unlikely to find a perfect match 
for a Web service. The reason can be, for instance, the different number 
of input or output parameters, but perhaps above all, the semantic meaning 
of the input and output parameters. The ontology and its ability to cover 
the concepts used in the semantic descriptions is maybe the most important 
issue in the semantic matching. In the worst case the concept presented in 
the semantic description is not found in the ontology, which means that the 
corresponding Web service cannot be used by the semantic matching phase 
at all. 

The semantic matching of the Web services presented in this chapter 
considers the search space as flat, which results in problems with scalabil- 
ity, when the number of available Web services increases. This could be 
leveraged, if the search space could be narrowed down before the semantic 
matching. However, this would require some a priori knowledge about the 
available Web services. One approach would be to combine a multiview- 
based search with the semantic matching. In the multiview-based search 
the idea is to organize the terminology (the semantic descriptions of the 
Web services) into a orthogonal hierarchies and use them extensively in the 
query [17]. By making projections of the search space based on the multi- 
ple views in the query, the search space can be narrowed dowd by leaving 
out the irrelevant Web services. Another approach could be the utilization 
of Web service containers, as introduced in [7]. However, these kinds of 
optimizations remain as future work. 

The UDDI [24] is a natural choice as a repository for Web services, so 
our Web service directory could be implemented by UDDI. In [26], the 
authors describe an approach of “wrapping” UDDI with semantic layer. 
In this chapter we separated the Web service directory from the semantic 
description database for the following reasons. Firstly, the UDDI does not 
allow querying semantically annotated advertisements. Secondly, we want 
to maintain compatibility to the existing Web services that are using UDDI. 
If the UDDI evolves to support semantically meaningful advertisements, 
we can integrate the semantic description database into the UDDI. These 
issues are out of this chapter’s scope and remain as future work. 
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7. CONCLUSION 

In this chapter we have discussed the composition of Web service work- 
flows, where one of the objectives is to automatise the process of finding 
and matching the Web services accessed by the workflow. We introduced a 
model for composing Web service workflows. The central part in the sys- 
tem is played by the workflow composer agent, which is able to compose 
Web service workflows, and more importantly, uses semantic descriptions 
of Web services in finding and matching Web services for a workflow. The 
matching algorithm operates on the preconditions, effects, inputs, and out- 
puts and utilizes semantic Web service ontologies in finding semantically 
similar Web services. The process of composing workflows is divided into 
four steps: processing the query, semantic matching, attaching of Web ser- 
vices to the workflow, and finally, executing the workflow. In the latter part 
of the chapter, we demonstrated workflow composition with an example 
scenario. We will continue with our work on improving the composition 
algorithm, particularly in terms of improved scalability and better handling 
of the preconditions and effects. 
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Abstract: Web service composition can provide a value-chain between customers and 

suppliers. The increasing number of services, and thus possible combinations, 
demands the development of dynamic and automatic techniques for their 
composition. Current commercial solutions are limited and are primarily static 
and manual. Automation requires reasoning about (semantic descriptions of) 
the services. This paper describes our initial work which brings together 
agents, Web service and semantic Web technology. Our knowledge-based 
software engineering approach to the design of agents, known as the Agent 
Factory, is applied to the composition of Web services. Using semantic 
descriptions of Web services written in DAML-S, the design process in our 
Agent Factory derives a Web service configuration. This paper also includes 
some observations regarding our experiences with DAML-S, UDDI and 
WSDL for this purpose. 



1. INTRODUCTION 

The Web offers organizations the opportunity to reach potential clients 
like never before: dynamically matching providers with requestors. 
However, this promise is also a challenge. The extensive collaborative work 
that is taking place concerning Web services (WSs) and the Semantic Web 1 
is taking up this challenge and is paving the way for realizing dynamic 
discovery and utilization of Web resources. 

The main goal of our work is to apply and extend our Agent Factory, an 
automated facility for composing software agents, to configure WSs. Our 
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approach is quite novel in that we treat WS composition as configuration of 
an artefact. Our findings are of benefit to the Web community of users and 
researchers as we offer a means by which services may be composed into 
more complex services. In particular, our findings are relevant to the 
Semantic Web community as we use the semantic descriptions of the Web 
services to determine what components were needed and how they fit 
together. Another goal of the work reported in this paper is to explore the 
state of the art, identify shortcomings and offer recommendations. Thus the 
work reported brings together the fields of agent-based, knowledge-based 
software engineering, Web service and Semantic Web technology. 

The next section introduces Web services and the contributions of the 
Semantic Web community to provide WSs with semantic descriptions. In 
Section 3 our Agent Factory is presented and our use of Web services as 
components is described. Section 4 describes an example of how the Agent 
Factory can be used for automated configuration of services. The steps 
needed to mark up service descriptions and an explanation of how these 
descriptions are used by our Agent Factory to compose a set of WSs, are 
provided. A discussion of the results, including a brief critique of DAML-S 
(DARPA Agent Markup Language for Services), UDDI (Universal 
Description, Discovery, and Integration of Web Services) and WSDL (Web 
Service Description Language), is given in Section 5. Conclusions and 
future work are described in the final section. 



2. WEB SERVICE EFFORTS 

A number of definitions of Web services exist. The definition that most 
fits with our intended use of WSs is given by the Stencil 11 group who define 
WSs as “loosely coupled, reusable software components that semantically 
encapsulate discrete functionality and are distributed and programmatically 
accessible over standard internet protocols”. The definition captures the 
self-contained, modular, composable and distributed nature of WSs. 

The utility of Web services relies on the ability to publish, find, browse, 
select, compose, employ and monitor Web services. Current technology 
relies on humans to perform most of these tasks. For example, UDDI 
provides an XML-based schema for describing such aspects as the owner of 
the service, location and service indexes and categories, to determine if the 
service is what the user needs. To actually use it, it is necessary to either 
make contact with the provider or to browse one or more documents referred 
to in the UDDI specification. WSDL allows definition of a service interface 
and service implementation, but only at a syntactic level. Similarly, 




